Webware for Python

On 3/18/07, Christoph Zwerschke <cito@...> wrote:
> On webware-discuss I already announced that I want to release the next
> Webware version 0.9.3 very soon. If anybody has suggestions or patches
> or bug reports that I should take into account, please let me know.

I had a problem on Mac using Webware out of the repository where the
AutoReload feature would not work. I believe it threw an exception
related to importing modules, but it's been awhile.

I'll try to test it out this week and see if I can reproduce and fix it.

> What about the idea of releasing a 1.0 version without much change if
> the 0.9.3 turns out to be stable?

Sounds good to me. I had thought about suggesting the same thing.

> One big change I wanted to make is to require Python 2.3 or 2.4. This
> would allow us to remove a lot of old garbage and code many things
> simpler. It would be an opportunity to really clear out the code base.
> The question is should we do this before or after 1.0 because these
> refactoring will certainly bring some instability again. (Unfortunately,
> Webware's few tests do not cover very much.)

I really think we should up the requirement *after* 1.0 since we're so
close to 1.0 right now.

> The next big change could be the transition to more contemporary coding
> style and tools, naming conventions, using setuptools and getting rid of
> Webware's peculiar plug-in architecture. This would break backward
> compatibility more or less so it should be done in a new major version
> as well. I'm also not sure whether I or anybody else will have enough
> time and energy to ever tackle this. For new projects, it seems to make
> more sense to use one of the nice contemporary web frameworks. So it may
> be better to release the 1.0 now than never.

I guess the question is whether or not anyone will put in the time to
do these things. My particular wish is for more properties and less
methods. For example, self.request.urlPath. But I was hoping a nicer
syntax for properties would have been added to Python by now!

Note that backward compatibility can still be maintained by having
WebKit.Object __call__() return self.

I also have a setUp() and tearDown() for servlets that don't require a
parameter or calling super (unlike awake/sleep). I've been using them
locally, but they're not checked in.

I also have a bunch of reusable code which I felt I didn't have time
to document and support properly...

I'm still using Webware, but I'm also pretty busy and Webware does
what I need it to do. That makes it hard for me to find time for
enhancing it.

And btw we all appreciate your efforts, Christoph! You've been great
for the project.


-Chuck

On Mar 19, 2007, at 8:53 AM, Chuck Esterbrook wrote:

> And btw we all appreciate your efforts, Christoph! You've been great
> for the project.

Allow me to ditto that remark. Your work, Christoph, is a tremendous  
benefit to the Webware project.

Many thanks,

Mark Phillips

Chuck Esterbrook wrote:
> I had a problem on Mac using Webware out of the repository where the
> AutoReload feature would not work. I believe it threw an exception
> related to importing modules, but it's been awhile.
> I'll try to test it out this week and see if I can reproduce and fix it.

Unfortunately I have no Mac experience and equipment, so it will be good 
if you check this. The only thing I did last time was running the tests 
on a Mac in the SourceForge compile farm, but that probably didn't cover 
the AutoReload feature.

> I really think we should up the requirement *after* 1.0 since we're so
> close to 1.0 right now.

Ok. I'll postpone major changes until then. We can then maintain the 
stable branch as 1.0.x and continue with 1.1 or 2.0 depending on how 
radically we're going to change and break things, or maybe we make two 
steps. I like your idea of properties with the __call__ hack for 
backward compatibility.

Another question is whether we should support WSGI and develop Webware 
in a similar direction as Ian's "Wareweb", maybe reusing some of his 
idea and code.

Btw, how do you think about the transition from tabs to spaces? Before 
1.0, after 1.0, or never? ;-) 4 spaces are standard per PEP 008, and it 
seems they will even become standard for C sources of Python 3K.

-- Chris

On 3/19/07, Christoph Zwerschke <cito@...> wrote:
> Chuck Esterbrook wrote:
> > I had a problem on Mac using Webware out of the repository where the
> > AutoReload feature would not work. I believe it threw an exception
> > related to importing modules, but it's been awhile.
> > I'll try to test it out this week and see if I can reproduce and fix it.
>
> Unfortunately I have no Mac experience and equipment, so it will be good
> if you check this. The only thing I did last time was running the tests
> on a Mac in the SourceForge compile farm, but that probably didn't cover
> the AutoReload feature.
>
> > I really think we should up the requirement *after* 1.0 since we're so
> > close to 1.0 right now.
>
> Ok. I'll postpone major changes until then. We can then maintain the
> stable branch as 1.0.x and continue with 1.1 or 2.0 depending on how
> radically we're going to change and break things, or maybe we make two
> steps. I like your idea of properties with the __call__ hack for
> backward compatibility.
>
> Another question is whether we should support WSGI and develop Webware
> in a similar direction as Ian's "Wareweb", maybe reusing some of his
> idea and code.
>
> Btw, how do you think about the transition from tabs to spaces? Before
> 1.0, after 1.0, or never? ;-) 4 spaces are standard per PEP 008, and it
> seems they will even become standard for C sources of Python 3K.

What about Ar18@... suggestion:
"""
What if you stayed with tabs and then added a converter, so that you
can quickly convert the tabs to the number of spaces that you want?
In fact, this might be a good idea for a lot of free source Python
projects distributed on the web -- though I would suspect it would be
better to use tabs as the default and offer the ability to convert to
space because sometimes it's possible it might not look quite right
converting a project coded for spaces to tabs.
"""

It allows everyone to use their favorite approach.

You mentioned something about patches being a mess, but I don't see
why. People could send in patches as "all spaces" or "all tabs" or am
I not thinking of something?

I suppose there would then be a burden on people who use spaces to
invoke a script prior to checkin, but could that also be done via a
script? Something like:

# ci
tabify -r .
svn ci $*
spacify -r .

The "-r ." could actually be the default behavior of tabify and spacify.
The ci script could be put in your path.

Would this make life better?

-Chuck

Chuck Esterbrook schrieb:
> What about Ar18@... suggestion:
> """
> What if you stayed with tabs and then added a converter, so that you
> can quickly convert the tabs to the number of spaces that you want?
> In fact, this might be a good idea for a lot of free source Python
> projects distributed on the web -- though I would suspect it would be
> better to use tabs as the default and offer the ability to convert to
> space because sometimes it's possible it might not look quite right
> converting a project coded for spaces to tabs.
> """
> 
> It allows everyone to use their favorite approach.
> 
> You mentioned something about patches being a mess, but I don't see
> why. People could send in patches as "all spaces" or "all tabs" or am
> I not thinking of something?

I saw the problem in converting to the number of spaces "that you want". 
  As long as the converter uses a fixed size, it would not be a mess.

It still would be inconvenient, because you always have to think about 
this issue and either convert back and forth manually, or use a script, 
or change the settings in your editor. I'm working with a lot of Python 
code from various sources, and they all use 4 spaces for indentation 
since it's recommended in PEP8. I do not even need to think about tabs 
and tab sizes any more, it's only Webware where I need to worry.

It's not a big deal and I can live with tabs very well, but if we want 
to change, this release would be a good opportunity.

> I suppose there would then be a burden on people who use spaces to
> invoke a script prior to checkin, but could that also be done via a
> script? Something like:
> 
> # ci
> tabify -r .
> svn ci $*
> spacify -r .

I'm not sure how to do this on the server (repository) side. On the 
client side people also use IDEs or TortoiseSVN to check code in. And 
this should only run for Webware, not for other projects. Generally I 
don't like too much automagic because then you always have to worry 
whether it is really active etc.

-- Chris

On 3/20/07, Christoph Zwerschke <cito@...> wrote:
> Chuck Esterbrook schrieb:
> > What about Ar18@... suggestion:
> > """
> > What if you stayed with tabs and then added a converter, so that you
> > can quickly convert the tabs to the number of spaces that you want?
> > In fact, this might be a good idea for a lot of free source Python
> > projects distributed on the web -- though I would suspect it would be
> > better to use tabs as the default and offer the ability to convert to
> > space because sometimes it's possible it might not look quite right
> > converting a project coded for spaces to tabs.
> > """
> >
> > It allows everyone to use their favorite approach.
> >
> > You mentioned something about patches being a mess, but I don't see
> > why. People could send in patches as "all spaces" or "all tabs" or am
> > I not thinking of something?
>
> I saw the problem in converting to the number of spaces "that you want".
>   As long as the converter uses a fixed size, it would not be a mess.

Why couldn't it be to the number "that you want" and then back? That
might be nice. Some people like 2, some 3 and some 4. A clever tabify
could even detect it.

But nevermind because I see your point further below.

> It still would be inconvenient, because you always have to think about
> this issue and either convert back and forth manually, or use a script,
> or change the settings in your editor. I'm working with a lot of Python
> code from various sources, and they all use 4 spaces for indentation
> since it's recommended in PEP8. I do not even need to think about tabs
> and tab sizes any more, it's only Webware where I need to worry.

Well, actually why do you need to worry? I set my editor to Tab Size =
4 years ago and that was it. You can even do Tab = 3 or Tab = 2 if
your preference is different than mine.

> It's not a big deal and I can live with tabs very well, but if we want
> to change, this release would be a good opportunity.

Ah ha! You said, "I can live with tabs very well."

But even if we did it, I'd prefer any major change after the 1.0 release.

> > I suppose there would then be a burden on people who use spaces to
> > invoke a script prior to checkin, but could that also be done via a
> > script? Something like:
> >
> > # ci
> > tabify -r .
> > svn ci $*
> > spacify -r .
>
> I'm not sure how to do this on the server (repository) side. On the
> client side people also use IDEs or TortoiseSVN to check code in. And
> this should only run for Webware, not for other projects. Generally I
> don't like too much automagic because then you always have to worry
> whether it is really active etc.

Yeah I see what you're saying about IDEs, Tortoise, etc. Good point.

I still think that leaving tabs in place allows people to set the size
to what they want.

I read that Guido likes 4 spaces, but Google, where he now works,
mandates 2. If Guido had mandated tabs and tabs only (1 per indent)
then people could use whatever they want. If he's now mandating 4
spaces for future versions of Python, then he's ramming his preference
down his coworkers' throat. (In this argument, I'll also add a rule of
"no tabs after indentation".) On the other hand, maybe he has other
reasons for doing it ("normalizing" Python source code appearance in
print, for example).


-Chuck

I hadn't expected the issue is still so controversial ;-)

>> It still would be inconvenient, because you always have to think about
>> this issue and either convert back and forth manually, or use a script,
>> or change the settings in your editor. I'm working with a lot of Python
>> code from various sources, and they all use 4 spaces for indentation
>> since it's recommended in PEP8. I do not even need to think about tabs
>> and tab sizes any more, it's only Webware where I need to worry.
> 
> Well, actually why do you need to worry? I set my editor to Tab Size =
> 4 years ago and that was it. You can even do Tab = 3 or Tab = 2 if
> your preference is different than mine.

The point is I have set my editor to spaces instead of tabs. Now when I 
edit a Webware file without thinking of that (I usually don't use 
visible whitespace), then I produce files with mixed tabs and spaces. 
Ok, I can install a tabification mechanism before saving or checking in, 
but I don't want to run this on other sources which use spaces.

> Ah ha! You said, "I can live with tabs very well."

Yes. But without them I could live even better ;-)

Anyway, since you consider it a major change and still like tabs, let's 
keep tabs for the time being. In the next major version, when we 
modernize the code and much of it will be changed anyway (if this ever 
happens), we should seriously discuss this again. Maybe Guido has 
already changed the Google conventions by then ;-)

-- Christoph