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? --amk
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.
Well, lib-old got added back to the path to support external users (since the deprecated ConfigParser name will emit a warning only under the -3 Py3k warning flag). Since it would be nice for the standard library to not emit any warnings with the -3 flag, perhaps distutils should at least be trying the new name first, and only falling back to the old name on an ImportError (assuming we do decide we want to be able to run the 2.6 distutils on older versions of Python). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Thu, May 15, 2008 at 6:49 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Since it would be nice for the standard library to not emit any warnings with the -3 flag, perhaps distutils should at least be trying the new name first, and only falling back to the old name on an ImportError (assuming we do decide we want to be able to run the 2.6 distutils on older versions of Python).
Well, that is a good idea. And, that will silence the Windows buildbots while other developers find out how to add lib-old/ to the sys.path. -- Alexandre
On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling <amk@amk.ca> 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?
The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility. -Brett
On Thu, May 15, 2008 at 4:04 PM, Brett Cannon <brett@python.org> wrote:
On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling <amk@amk.ca> 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?
The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility.
-Brett
backwards compatibility? whats wrong with just doing: try: import configparser as ConfigParser except ImportError: import ConfigParser in the distutils code that needs to be.
On Thu, May 15, 2008 at 9:08 PM, Gregory P. Smith <greg@krypto.org> wrote:
On Thu, May 15, 2008 at 4:04 PM, Brett Cannon <brett@python.org> wrote:
On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling <amk@amk.ca> 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?
The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility.
-Brett
backwards compatibility? whats wrong with just doing:
try: import configparser as ConfigParser except ImportError: import ConfigParser
in the distutils code that needs to be.
Nothing's wrong with it. It's just that Alexandre did what we have done for all of the stdlib and just moved entirely over to the new name. -Brett
A.M. Kuchling wrote:
* 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?
I remember this discussion coming up before the 2.5 release when the distutils version number was changed to depend on the python instance instead of a static string. MAL was made very upset that the SVN trunk version of distutils could no longer be pulled out seperately. But at that time, you had removed it from PEP 291, officially renouncing this practice. I believe the conclusion was that MAL's request to maintain psuedo-backward-compatibility would be upheld despite not having official status. http://mail.python.org/pipermail/python-dev/2006-August/068250.html -Scott -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
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
participants (7)
-
A.M. Kuchling -
Alexandre Vassalotti -
Brett Cannon -
Gregory P. Smith -
M.-A. Lemburg -
Nick Coghlan -
Scott Dial