On Thursday 27 July 2006 16:40, Martin v. Löwis wrote:

Collin Winter wrote:

...

Is it intentional that Python 2.5 is (currently) shipping with distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3) shipped with distutils 2.4.1? Judging from my own tests, distutils 2.4.1 fixed several bugs that some of my test suites depend on (the fixes, not the bugs ; ).

Are these bugs not fixed in the distutils that shipped with Python 2.5b2?

In any case, I bumped the version number to 2.5, according to the policy discussed in

Could this not simply use the Python version number directly, instead? Separate version numbers only make sense if the package is separately distributed - and even then, something like Barry's setup for the email package could keep that version number out of the Python trunk. Fiddly little version numbers scattered throughout the standard library == pain. Anthony

Martin v. Löwis wrote:

Anthony Baxter schrieb:

...

...

In any case, I bumped the version number to 2.5, according to the policy discussed in

Could this not simply use the Python version number directly, instead?

See the prior discussion at

http://mail.python.org/pipermail/distutils-sig/2005-January/004366.html

Some people still believe (at least, believed in January 2005), that distutils is developed independently of Python, and thus deserves its own version number.

They still do. Even if distutils is part of the stdlib, it is a software package that's intended to be used for more than just the latest Python release. The fact that were no official separate distutils releases shouldn't be regarded as meaning that there's no interest in using distutils with older Python versions.

Of course, Andrew Kuchling officially declared in r1982 of pep 291 that there won't be any further stand-alone distutils releases, and therefore, backwards compatibility with 2.1 is not necessary anymore.

AFAIK, there was no public discussion about this on the distutils SIG list. While I don't think that Python 2.1 compatibility is still a requirement, Python 2.3 compatibility should be maintained in order to make SVN distutils work with all versions of Python since 2.3. distutils should then be added back to PEP 291.

So I changed distutils.__version__ again, to be derived from sys.version_info.

See the discussion on the checkins list for why this will only cause problems instead of fixing any. http://mail.python.org/pipermail/python-checkins/2006-July/055139.html

I left the numerous comments still in distutils that compatibility with 2.1 is desired. We should remove these after 2.5 is released (or perhaps even before that).

Please don't. Instead we should have a discussion about this whole issue on the distutils list and then decide. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 01 2006)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::