Distutils & configparser rename
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 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
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
On 16 maj 2008, at 15.00, M.-A. Lemburg wrote:
On 2008-05-15 22:33, A.M. Kuchling wrote:
<snip>
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.
Speaking of which; is there any reliable statistics of Python versions and platforms? Would be really interesting!
On 2008-05-16 15:28, Rasmus Andersson wrote:
On 16 maj 2008, at 15.00, M.-A. Lemburg wrote:
On 2008-05-15 22:33, A.M. Kuchling wrote:
<snip>
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.
Speaking of which; is there any reliable statistics of Python versions and platforms? Would be really interesting!
Reliable statistics are hard to obtain, since Python is distributed along with many Unix distributions, as part of many products, and also in source form (where you basically lose any platform or Python version information). FWIW, these are the stats for our OSS Python package egenix-mx-base: Downloads egenix-mx-base 3.0 in 2008: Python 1.5.2: 0 Python 2.0 : 0 Python 2.1 : 31 Python 2.2 : 54 Python 2.3 : 483 Python 2.4 : 3368 Python 2.5 : 7504 Source ZIP : 4238 Source TGZ : 2918 These are just downloads, so likely new installations (the 3.0 version was released about one year ago). It's hard to tell what the installed user base looks like, esp with respect to the used Python versions. -- 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
On 16 maj 2008, at 15.47, M.-A. Lemburg wrote:
On 2008-05-16 15:28, Rasmus Andersson wrote:
On 16 maj 2008, at 15.00, M.-A. Lemburg wrote:
On 2008-05-15 22:33, A.M. Kuchling wrote:
<snip>
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. Speaking of which; is there any reliable statistics of Python versions and platforms? Would be really interesting!
Reliable statistics are hard to obtain, since Python is distributed along with many Unix distributions, as part of many products, and also in source form (where you basically lose any platform or Python version information).
FWIW, these are the stats for our OSS Python package egenix-mx-base:
Downloads egenix-mx-base 3.0 in 2008: Python 1.5.2: 0 Python 2.0 : 0 Python 2.1 : 31 Python 2.2 : 54 Python 2.3 : 483 Python 2.4 : 3368 Python 2.5 : 7504 Source ZIP : 4238 Source TGZ : 2918
These are just downloads, so likely new installations (the 3.0 version was released about one year ago). It's hard to tell what the installed user base looks like, esp with respect to the used Python versions.
Thank you. That's better than nothing alright!
-- 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 (6)
-
A.M. Kuchling -
Brett Cannon -
Gregory P. Smith -
M.-A. Lemburg -
Nick Coghlan -
Rasmus Andersson