[Python-Dev] Re: Patch level versions and new features (Was: Some dull gc stats)

[M.-A. Lemburg]

Barry A. Warsaw wrote:
>>>>>>"MAL" == M  <mal@lemburg.com> writes:
>>>>>
> 
>     MAL> Adding the argument would only help applications which would
>     MAL> make use of it. An application written for Python 2.2
>     MAL> couldn't do this since the optional argument wouldn't be
>     MAL> available.
> 
> Ok, here's another question.  When I updated the email package in
> Python 2.3, Guido wanted me to backport it to Python 2.2.x.  I did
> that once, but there's been a lot of changes since then, both bug
> fixes, API "fixes", and new functionality.
> 
> The email package can be installed separately as a distutils package,
> and it is compatible all the way back to Python 2.1.x.  Which means
> someone /could/ install the latest version in their site-packages and
> have the new functionality in any of the last 3 versions of Python,
> although it would be tricky for Python 2.2.1.
> 
> So does it make sense to backport the latest email package to Python
> 2.2.2?  That's what Guido wanted, and I could argue that doing so
> improves stability of that branch, because while it adds a lot of new
> stuff, the old stuff was fairly well broken.  E.g. you can't properly
> encode RFC 2047 headers in Python 2.2.1's email package.  Backporting
> allows application writers to fix their code so that it works
> compatibly and correctly across more versions of Python than if we
> didn't backport.  It also makes no sense to maintain two different
> code bases (especially now that that's been reduced from 3! :).
> 
> OTOH, it definitely adds new features.  Maybe email is special because
> it was so new in Python 2.2, and so I took a more naive approach to
> some issues that a wider use uncovered.
 >
> it-ain't-always-simple-ly y'rs,

Never said it was... :-)

For cases like the email package or distutils, I think it's
perfectly OK to only provide the updates for older Python
releases as separate download. Both have their own way of
life, so IMHO this is acceptable.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/