Hi Paul,
On 11/12/05, Paul Clifford <[EMAIL PROTECTED]> wrote:
> I have a patch against revision 182 of the trunk to make TurboGears
> work with Python 2.3. It does the following:
Hey, cool! Maybe I should post a message to the mailing list
requesting the upcoming winning lottery numbers. Or is that pressing
my luck? :)
> * All decorators change from:
> @decorate
> def fn(...):
> ...
> to
> def fn(...):
> ...
> fn = decorate(fn)
Sounds good. This is, from my understanding, the general idiom (rather
than the wrap function you mention below). Better to stick with the
understood convention. (This is also what I've been doing in my recent
use of decorators in the code.)
> * All generator expressions become list comprehensions.
Did we have generator expressions? Intriguing. That's not a feature
I've used much myself.
> * Attempts to change <fn>.func_name are wrapped in a try/except so
> that the TypeError thrown under 2.3 can be ignored.
Good catch. I wouldn't have guessed at that one. This might make
debugging tricker. I'm not sure if there's any other reason I was
trying to change the func_name.
>
> * Any modules where set or frozenset is used have the following
> prelude added:
>
> try:
> set, frozenset
> except NameError:
> from sets import Set as set, ImmutableSet as frozenset
>
> (Except turbogears/command/__init__.py where I just changed the
> sets into lists.)
Seems reasonable.
> There are three further problems:
>
> 1. turbogears/identity/__init__.py makes use of threading.local(),
> which is a Python 2.4 addition.
This appears to be used to store who the user is for the current
request. I'd actually move that directly onto cherrypy.request.
> 2. FormEncode 0.3 is now Python 2.4 only due to the use of
> decorators.
Since decorators are just syntax sugar, Ian might be convinced to change those.
> 3. PasteScript uses various Python 2.4 library features.
>
>
> I patched FormEncode to remove the decorators, but rather than patch
> anything else I tried a different approach -- I added a
> "compat24.pth" file to site-packages which imports a module to do
> the following:
>
> * Add the "set", "frozenset", "reversed", and "sorted" builtins.
>
> * Implement string.Template (for PasteScript) and threading.local
> (for turbogears.identity) using code copied from Python 2.4.2
>
> I also copied the subprocess.py module (for PasteScript) from Python
> 2.4.2 to my site-packages directory. This fixes the remaining
> problems and I can successfully follow and run the TurboTunes
> tutorial (with changes to avoid the use of decorators).
Perhaps rather than requiring the .pth file, we could just add
something in turbogears/__init__.py to load up the required stuff if
you're running 2.3?
> Three questions:
>
> 1. Is this patch, or a variant on it, likely to be accepted? I'm
> willing to make sure future versions (at least up to 1.0)
> continue working under 2.3.
Yes. As I said, there have been enough requests for 2.3 support that
I'd like to try to accomodate, and I will go so far as to use only 2.3
idioms in TurboGears. (Docs and demos will still use 2.4 features...)
> 2. Should I make a separate 2.4-for-2.3 compatibility package
> available, or just move the threading.local implementation into
> the main patch and deal with PasteScript separately?
I believe the thread.local use can be eliminated. So, if the
PasteScript piece can be dealt with conveniently within TurboGears,
that would be a bonus.
> 3. An alternative reworking of the decorators could be something
> like:
>
> def wrap(fn, decorator):
> import sys
> sys._getframe(1).f_locals[fn.func_name] = decorator(fn)
>
> def fn(...):
> ....
> wrap(fn, decorator)
>
> (I know the above doesn't allow multiple decorators, but that can
> be fixed.) Is something like this desirable? It saves writing
> the function name twice and looks neater, but might be a bit too
> "magic".
It's not so much that it's magical... it's just not the convention.
Anywhere people write about decorators, they always say:
@property
def get_foo(self):
return self._foo
is the same as
def get_foo(self):
return self_foo
get_foo = property(get_foo)
Better to not try to throw something else in the mix. Besides, the
docs will generally be using the @ syntax anyhow, so such a thing
would likely appear only in a dark corner of the docs.
Looks like you've taken a pretty thorough look at the matter! Thanks
for taking the time, and it will be nice to be able to say that
TurboGears 0.9 is compatible with Python 2.3.
Kevin
