Jim Gallacher writes:
> Daniel J. Popowich wrote:
> > 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.
>
> I'll re-read this paragraph after a good sleep, but right now I'm not
> sure if you mean we shouldn't be using features only available in newer
> python versions, or we shouldn't worry about compatibilty with with
> older python versions?
AND...
Nicolas Lehuen writes:
> 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.
I can reply to both in one swell foop:
I mean we cannot overly concern ourselves with earlier versions of
python. I say "overly" because I do believe, very strongly, that we
need to say definitively this-version-of-mod_python is dependent on
this-version-of-python-and-above. So, we need to be careful when
making such declarations, but once agreed upon and published, then we
need not worry ourselves about previous versions. Any hacks of the
sort I recommended (PythonImport based ones) are out of the mainstream
and published in the FAQ or as examples in the source tarball, but not
included in the installed library.
Why not in the official library? Because of the scalability of such
solutions; actually the lack of scalability. I disagree that 'from
python22 import *' (or PythonImport hacks) are no more troublesome
than 'from __future__ import XYZ' because it all depends on the point
of view of the programmer. Of course, from the perspective of the 2.2
user there is no difference: it's just one import, but that's not our
perspective...we're not explicitly 2.2 users...we're developers of a
platform based on a language. If we offer 2.2 backwards compatibility
we have to KNOW with certainty we've covered our 2.3 tracks.
Personally, I want to develop mod_python, not reimplement 2.3 in
2.2.
If I'm programming in a 2.2 universe and the publishers of the
language have said in 2.3 such-and-such a feature will be made
available and you can use it now with 'from __future__' that is very
useable and scalable. The list of features is small and presumably
the interoperabilites well tested. When 2.3 comes out and I adopt its
use, my code doesn't change.
If I'm programming in a 2.3 universe and I'm worried about users of my
software who use previous versions of 2.2 I have to know,
definitively, every feature of 2.3 I'm using not in 2.2. Use of
enumerate is easy to find. But there are WAY more diffs than
enumerate and do we know for a fact our test cases exercise
everything? I ran the following command inside the 2.3 library
documentation directory:
% grep 'New in version 2\.3' *.html|wc -l
148
Are we sure we're not using any of the 148? Of course, it gets
worse as time goes on. The diffs between 2.4 and 2.2? Whew.
It may be painful, but as developers of mod_python we HAVE to know
what version of python it is based on and we can use only that version
to code, BUT have to test ALL versions higher. I.e., if we say
mod_python is based on python 2.2 and higher then we can only develop
in 2.2, but test 2.2, 2.3 and 2.4. If we say it's based on 2.3 then
we develop with 2.3 and test 2.3 and 2.4, etc. Following this logic
it makes sense to keep moving forward with python (else 2.2 code
begins to break because it's using deprecated code in future versions
and/or our testing becomes very painful as we need to certify our old
code against newer versions).
My gut says any major release of mod_python be based on one
major.minor release lower than the currently available python. So,
mod_python 3.2 is based on python 2.3; mod_python 3.3 will probably be
based on python 2.4 (because 2.5 will be out by then).
Cheers,
Daniel Popowich
---------------
http://home.comcast.net/~d.popowich/mpservlets/
PS
If it's not obvious I'm gearing up to get way more involved...I've
been waiting (patiently) for 3.2 to be released and jump in with new
3.3 development...I guess I'm chomping at the bit...
