Kevin Dangoor wrote:
[ ... ]
> So, in a nutshell: 2.3 support is possible because 2.3 is supported by
> CherryPy, SQLObject and Kid. If someone wants to verify 2.3 versions
> of TurboGears, I'm fine requiring that the TurboGears core uses only
> 2.3 features.
I have a patch against revision 182 of the trunk to make TurboGears
work with Python 2.3. It does the following:
* All decorators change from:
@decorate
def fn(...):
...
to
def fn(...):
...
fn = decorate(fn)
* All generator expressions become list comprehensions.
* Attempts to change <fn>.func_name are wrapped in a try/except so
that the TypeError thrown under 2.3 can be ignored.
* 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.)
There are three further problems:
1. turbogears/identity/__init__.py makes use of threading.local(),
which is a Python 2.4 addition.
2. FormEncode 0.3 is now Python 2.4 only due to the use of
decorators.
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).
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.
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?
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".
