On 2008-05-15 22:33, A.M. Kuchling wrote:
Python 2.6 renames the ConfigParser module to be configparser.
Distutils imports ConfigParser in various places. I just made a
commit updating the import in one places, and then noticed that part
of commit r63248, which made the same change, was reverted in order to
preserve backward-compatibility. Instead, the default path will
include lib-old again to keep the old module name available.
I suggest dropping that goal, though. We've preserved compatibility
but I'm not aware that anyone uses the Python 2.x Distutils with
earlier versions of Python. In particular:
* There's no standalone distutils package on PyPI, nor can I find
such a package with a general web search. Am I missing it?
* I do not see users advising other users to use a later version of
Distutils to fix their problems.
Is anyone actually benefiting from the effort of maintaining backward
compatibility?
Yes: all the folks who want to create distutils packages for more than
just the current Python version.
I've argued for this a couple of times in the past. Some background:
In order to build a Python package for a previous Python version,
you have to run distutils using that older Python version.
Now, as distutils evolves, new features are added, bugs are fixed,
etc. so as packager you always want to use the latest distutils
version available - even with older Python releases. In some cases,
e.g. PyPI registration, this may even be necessary, since the
new versions of those commands need to be kept in sync with the
PyPI repository.
Another aspect is keeping package setup.py files working.
If you need to support multiple Python versions, then your
setup.py will have to work with multiple different versions
of distutils.
Since performance doesn't really matter for distutils, it is well
possible and easy to keep compatibility with a few releases back.
This has worked great in the past and I don't see why we should
break this, as recent distutils checkins have done.
Note that Python doesn't exactly make it easy to ship Python
packages. You have several different dimensions to take into
consideration:
* Python version
* UCS2/UCS4
* Platform and processor type
* 32/64-bit
So there already is a lot of porting effort needed to support
a reasonable number of targets.
I don't think it takes a lot of effort to keep distutils
running with Python 2.3 and 2.4.
In the past I've usually rewritten parts of distutils that
were modified in incompatible ways. I haven't been able to
that for the recent checkins that broke distutils even on
Python 2.4.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, May 16 2008)
>>> 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,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
