Barry A. Warsaw wrote:
"MAL" == M email@example.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.
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.