Quick response, because it's 4:36 AM here, I just woke up to feed my daughter and took all this flak, but I need to sleep :). I guess that's the problem of having a round-the-planet development team, between those in America, Europe, Asia and Australia (nobody from Antarctica yet ?)
Graham : Considering that Grisha wanted your fix for the connection handler included in the 3.2 release, I thought that the 3.2.6 release was DOA, so I didn't feel bad about checkin this in. Anyway, Jim has the good idea there : We've got a clean 3.2.6 tag, so we can release it and either branch on it or stay on the trunk. We don't have to stop everything just because we want to release something, Subversion is here to help. Daniel : I think that "from python22 import *" is no more troublesome as the "from __future__ import generators" that you have to put in any source code that feature generators and needs to run from Python 2.2 and upward. But that's a matter of taste. Maybe we could do something like you wrote, for example in a mod_python.python22support module that Python 2.2 users would import using PythonImport ? The only problem is that the current solution passes all the test suite from Python 2.2 to Python 2.4 (I've yet to test it on Python 2.5), whereas a solution using PythonImport or any custom tweaking of the configuration would require a special case in the test suite. Now I'm going back to sleep. Regards, Nicolas 2006/2/2, Daniel J. Popowich <[EMAIL PROTECTED]>: > > Nicolas Lehuen writes: > > I've just checked in some changes to the Python source code in order > > to support Python 2.2. Now the test suite runs successfully on Python > > 2.2.3 on Windows 2000. I've checked that no regressions were > > introduced in later Python versions, too. > > > > The changes are pretty simple : each Python module now features a > > "from python22 import *". The mod_python.python22 module just > > reimplements new builtins from Python 2.3. It turns out that the only > > missing builtin for now is enumerate(). The tests module, containing a > > few tests for generators, has to sport a "from __future__ import > > generators" line. > > > > I also had to change mod_python.cache which used time.strptime so that > > it uses rfc822.parsedate, now. > > > > I've did this because the guys from Nokia use Python 2.2 and > > mod_python 3.1.3. They spotted memory leaks which are likely to be > > fixed in mod_python 3.2.X, but they could not upgrade if Python 2.2 > > was not supported. > > But does this scale over the life of a project? Every new python > module has to include 'from python22 import *'?? > > While never shying away from a decent hack myself, this is a hack that > affects everyone, not just those that need the hack, which, for me, > screams volumes. > > Certainly, which version of python mod_python is based on should not > be taken lightly. Was it formally decided to make mod_python > dependent on 2.3+? If not, then perhaps uses of enumerate, > etc. should not be used. > > If a formal decision was made, then it's a done deal, right? If not > and uses of 2.3 have slipped in then perhaps it's a done deal anyway > because no one can stomach the thought of taking out the 2.3-isms at > this late date. > > Regardless, I do not think it is within the scope of mod_python > developers to keep users forward-compatible with the underlying python > version. Sorry, but IMHO, this is not scalable software engineering. > > That said, I don't have a problem helping 2.2 users write their own > hacks. For example, let's take enumerate...another way of solving > this problem without touching any mod_python code would be a > suggestion in the FAQ to write a module, say, python22hacks.py: > > ------------------------------------------------------------ > # python22hacks.py > # > # This is unsupported software offered to mod_python users who are > # stuck using python 2.2. > # > # Install by placing this module in the same directory with other > # mod_python modules and add the following to your apache config: > # > # PythonImport python22hacks INTERPRETER_NAME > # > # More disclaimers, blah, blah... > > import __builtin__ as hack > > hack.enumerate = lambda s: zip(xrange(len(s)), s) > ------------------------------------------------------------ > > This way we don't have to touch every module of source code and the > onus is on the few who need it rather than the many who don't or those > who have to maintain it. > > Cheers, > > Daniel Popowich > --------------- > http://home.comcast.net/~d.popowich/mpservlets/ >
