Making distutils string-free?
I notice distutils still imports the string module instead of using string methods. Is it still necessary that this codebase runs with Python 1.5.2? If not, someone can start working on removing the string module references. (The sre module needs to run under 1.5.2, per agreement with /F, so it has to keep using the string module.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On 31 May 2002, Guido van Rossum said:
I notice distutils still imports the string module instead of using string methods. Is it still necessary that this codebase runs with Python 1.5.2?
No, I think that requirement can safely be dropped now.
If not, someone can start working on removing the string module references.
Fine by me! Greg
Guido van Rossum wrote:
I notice distutils still imports the string module instead of using string methods. Is it still necessary that this codebase runs with Python 1.5.2? If not, someone can start working on removing the string module references. (The sre module needs to run under 1.5.2, per agreement with /F, so it has to keep using the string module.)
distutils has to maintain 1.5.2 compatibility. Please don't change anything which would cause this to break. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/
On 31 May 2002, M.-A. Lemburg said:
distutils has to maintain 1.5.2 compatibility. Please don't change anything which would cause this to break.
Isn't it enough that Distutils 1.0.1 or 1.0.2 or whatever-it-is is available for Python 1.5.2? At some point, the Distutils distributed with Python should catch up with modern Python coding conventions. Now's as good a time as any. Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ War is Peace; Freedom is Slavery; Ignorance is Knowledge
distutils has to maintain 1.5.2 compatibility. Please don't change anything which would cause this to break.
Really? Why? Isn't the existing standalone distutils distribution good enough? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
distutils has to maintain 1.5.2 compatibility. Please don't change anything which would cause this to break.
Really? Why? Isn't the existing standalone distutils distribution good enough?
No, it's still missing important support for FreeBSD, Debian and some other packages. Also, bug fixes should be easily had for package writers who wan't to maintain 1.5.2 compatibility. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/
No, it's still missing important support for FreeBSD, Debian and some other packages. Also, bug fixes should be easily had for package writers who wan't to maintain 1.5.2 compatibility.
Sigh. OK, let's hold off on "fixing" distutils. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
No, it's still missing important support for FreeBSD, Debian and some other packages. Also, bug fixes should be easily had for package writers who wan't to maintain 1.5.2 compatibility.
Sigh. OK, let's hold off on "fixing" distutils.
Side-note: distutils isn't performance sensitive and string methods don't buy you anything else since Unicode is not used in distutils. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/
Martin v. Loewis wrote:
"M.-A. Lemburg" <mal@lemburg.com> writes:
Side-note: distutils isn't performance sensitive and string methods don't buy you anything else since Unicode is not used in distutils.
That is not true: msvccompiler has to deal with Unicode in the registry.
"Dealing" with it is not using it :-) msvccompiler only tries to encode the registry entry into a string and then goes on to process the string. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/
>> distutils has to maintain 1.5.2 compatibility. Please don't change >> anything which would cause this to break. Guido> Really? Why? Isn't the existing standalone distutils Guido> distribution good enough? Porting changes between the in-core and standalone versions of distutils would be more difficult if the former used string methods and the latter used the string module. Skip
Guido van Rossum wrote:
I notice distutils still imports the string module instead of using string methods. Is it still necessary that this codebase runs with Python 1.5.2? If not, someone can start working on removing the string module references. (The sre module needs to run under 1.5.2, per agreement with /F, so it has to keep using the string module.)
There's also some uses of string in xml/, compiler/, and lib-tk/Tix.py. Can these all be removed? Neal
On Fri, May 31, 2002 at 10:37:17AM -0400, Neal Norwitz wrote:
There's also some uses of string in xml/, compiler/, and lib-tk/Tix.py. Can these all be removed?
The use of 'string' in xml/ likely stems from the original PyXML code aiming to run with 1.5.2. Adding string methods will cause divergence from the PyXML code base for no good reason; I'd suggest leaving it alone. String methods will appear as the PyXML code begins to use them. As for Distutils, I again don't see the need to use string methods everywhere. (Though admittedly I have no plans to issue a standalone release again, and presumably neither does Greg.) --amk
It looks like a decent guideline is: make individual modules string-module-free, but don't touch large packages. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
It looks like a decent guideline is: make individual modules string-module-free, but don't touch large packages.
Indeed :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/
There's also some uses of string in xml/, compiler/, and lib-tk/Tix.py. Can these all be removed?
I don't know if the xml/ codebase has a backwards compat requirement. I can't imagine compiler/ does, so go ahead there. Ditto for Tix.py. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org> writes:
There's also some uses of string in xml/, compiler/, and lib-tk/Tix.py. Can these all be removed?
I don't know if the xml/ codebase has a backwards compat requirement.
The current requirement is that it ought to be 2.0-compatible (1.5.2 compatibility was just dropped). So using string methods is fine; using type builtins is not. Regards, Martin
I don't know if the xml/ codebase has a backwards compat requirement.
The current requirement is that it ought to be 2.0-compatible (1.5.2 compatibility was just dropped). So using string methods is fine; using type builtins is not.
Great! It looks like there are only a few places where the string module is used: 3 in minidom.py, 2 in sax/_init__.py, 3 in sax/expatreader.py. Neal? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I don't know if the xml/ codebase has a backwards compat requirement.
The current requirement is that it ought to be 2.0-compatible (1.5.2 compatibility was just dropped). So using string methods is fine; using type builtins is not.
Great! It looks like there are only a few places where the string module is used: 3 in minidom.py, 2 in sax/_init__.py, 3 in sax/expatreader.py. Neal?
That's what I found, checkin coming soon. Neal
participants (8)
-
Andrew Kuchling -
barry＠zope.com -
Greg Ward -
Guido van Rossum -
M.-A. Lemburg -
martin＠v.loewis.de -
Neal Norwitz -
Skip Montanaro