Should the use of deprecated functions in the stdlib be removed? string.atoi -> int string.atof -> float sys.exc_trackback -> sys.exc_info()[2] Should the methods which use gopher also be deprecated? ConfigParser.py:311: string.atoi is deprecated ConfigParser.py:314: string.atof is deprecated Cookie.py:331: string.atoi is deprecated inspect.py:658: sys.exc_traceback is deprecated urllib2.py:103: Module gopherlib is deprecated urllib.py:381: Module gopherlib is deprecated (Line #s aren't exactly correct, but problems exist in CVS.) Neal
Should the use of deprecated functions in the stdlib be removed? string.atoi -> int string.atof -> float sys.exc_trackback -> sys.exc_info()[2]
Sure.
Should the methods which use gopher also be deprecated?
Is the gopher protocol really dead? Maybe we deprecated it a little too soon; isn't it still in use at some places? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Should the methods which use gopher also be deprecated?
Is the gopher protocol really dead? Maybe we deprecated it a little too soon; isn't it still in use at some places?
gopher://gopher.floodgap.com/0/v2/vstat says it could find "555 unique servers (counting host and port pairs)." Neal
Guido> Is the gopher protocol really dead? Neal> gopher://gopher.floodgap.com/0/v2/vstat Neal> says it could find "555 unique servers (counting host and port Neal> pairs)." Recent versions of Opera don't support gopher directly. I tried clicking the above link and Opera said: The address type requires the use of a proxy server. While it may not technically be dead, it certainly appears it's pulse is weak. Skip
While it may not technically be dead, it certainly appears it's pulse is weak.
"I'm not dead yet!" :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Apr 25, 2002, Guido van Rossum wrote:
Neal Norwitz:
Should the methods which use gopher also be deprecated?
Is the gopher protocol really dead? Maybe we deprecated it a little too soon; isn't it still in use at some places?
Yup. That's what I said last time around. I guess the deprecation still made it into the official docs. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ What if there were no rhetorical questions?
Aahz writes:
Yup. That's what I said last time around. I guess the deprecation still made it into the official docs.
I mark things when I think Guido wants the deprecation. I can change the docs if we need to. I see no specific need to deprecate the gopher module. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"Fred L. Drake, Jr." wrote:
Aahz writes:
Yup. That's what I said last time around. I guess the deprecation still made it into the official docs.
I mark things when I think Guido wants the deprecation. I can change the docs if we need to. I see no specific need to deprecate the gopher module.
gopherlib is deprecated in PEP 4. Neal
Neal Norwitz <neal@metaslash.com> writes:
Should the methods which use gopher also be deprecated?
On the deprecation of gopherlib: Shortly after I wrote the initial RFC, I got some comments that gopher, as a protocol, is not dead yet, and that hence gopherlib should not be deprecated. I'd like to hear opinions whether people still think this is the case today. Regards, Martin
"Martin v. Loewis" wrote:
Neal Norwitz <neal@metaslash.com> writes:
Should the methods which use gopher also be deprecated?
On the deprecation of gopherlib: Shortly after I wrote the initial RFC, I got some comments that gopher, as a protocol, is not dead yet, and that hence gopherlib should not be deprecated.
I'd like to hear opinions whether people still think this is the case today.
http://www.scn.org/~bkarger/gopher-manifesto gopher://gopher.browser.org/ -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"MAL" == mal <M.-A.> writes:
MAL> "Martin v. Loewis" wrote:
Neal Norwitz <neal@metaslash.com> writes:
Should the methods which use gopher also be deprecated?
On the deprecation of gopherlib: Shortly after I wrote the initial RFC, I got some comments that gopher, as a protocol, is not dead yet, and that hence gopherlib should not be deprecated.
I'd like to hear opinions whether people still think this is the case today.
MAL> http://www.scn.org/~bkarger/gopher-manifesto MAL> gopher://gopher.browser.org/ In case you haven't followed these links yet or poked around in the odd alternate universe they describe <0.4 wink>, it looks like gopher is still kicking. My Mozilla browser supports it, and there seem to be a bunch of servers out there with current information. I think gopherlib should be un-deprecated. Jeremy
Jeremy> In case you haven't followed these links yet or poked around in Jeremy> the odd alternate universe they describe <0.4 wink>, it looks Jeremy> like gopher is still kicking. It appears there is a Python-based gopher client. From the gopher:// manifesto: Hot new gopher client (Python package!): http://opop.nols.com/proggie/forg-latest.tar.gz Looks like the most recent update was last September. I tried to run it but it requires Pmw. Skip
Neal Norwitz writes:
Should the use of deprecated functions in the stdlib be removed? string.atoi -> int string.atof -> float sys.exc_trackback -> sys.exc_info()[2]
Yes, especially that last one, since there are thread safety issues.
ConfigParser.py:311: string.atoi is deprecated ConfigParser.py:314: string.atof is deprecated Cookie.py:331: string.atoi is deprecated inspect.py:658: sys.exc_traceback is deprecated
These are now fixed in CVS. Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
"Fred L. Drake, Jr." wrote:
Neal Norwitz writes:
Should the use of deprecated functions in the stdlib be removed? string.atoi -> int string.atof -> float sys.exc_trackback -> sys.exc_info()[2]
Yes, especially that last one, since there are thread safety issues.
ConfigParser.py:311: string.atoi is deprecated ConfigParser.py:314: string.atof is deprecated Cookie.py:331: string.atoi is deprecated inspect.py:658: sys.exc_traceback is deprecated
These are now fixed in CVS. Thanks!
Great! Thanks, you saved me the work. I noticed your changes to use string methods. Should I change other uses? I've got diffs for: ftplib, markupbase, and tabnanny. Should I check those in? What are the modules that should keep backwards compatability with 1.5.2? It seems these are currently: inspect pydoc sre* xmlrpclib Is this correct? Are there others? Neal
On Thu, Apr 25, 2002 at 11:03:41PM -0400, Neal Norwitz wrote:
What are the modules that should keep backwards compatability with 1.5.2? It seems these are currently:
Add distutils/* to the list, too. I have no plans to issue future standalone releases for 1.5.2, but Greg Ward or someone else might. --amk
[Neal Norwitz]
.. What are the modules that should keep backwards compatability with 1.5.2? It seems these are currently:
inspect pydoc
The current versions of both those require 2.2. I didn't go out of my way to break 1.5.2 compatability when changing them for 2.2, but neither did I go out of my way to bury uses of new-in-2.2 staticmethod etc under obfuscating conditionals.
sre*
Yes, I believe Fredrik wants compatability there.
xmlrpclib
Dunno.
Neal Norwitz wrote:
What are the modules that should keep backwards compatability with 1.5.2? It seems these are currently:
In general, I think it's a good idea to be very careful about introduce flashy new stuff to the std lib since it makes backporting fixes harder, e.g. using Python 2.1 features is OK, but not 2.2 features (if not absolutely necessary or only if they are easily separatable from the rest of the code).
inspect pydoc
+0 on those
sre* xmlrpclib
+1 on those two
Is this correct? Are there others?
I suppose you should add the PyXML stuff (the part which is the std dist). Don't whether the PyXML team needs these bits for their standalone distributions, though. And distutils, as Andrew already mentioned. You should also keep in mind that porting to Jython should remain easily possible. Breaking that link would cause unnecessary work on the Jython side. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"MAL" == M <mal@lemburg.com> writes:
MAL> In general, I think it's a good idea to be very careful about MAL> introduce flashy new stuff to the std lib since it makes MAL> backporting fixes harder, e.g. using Python 2.1 features is MAL> OK, but not 2.2 features (if not absolutely necessary or only MAL> if they are easily separatable from the rest of the code). This is emerging as a common theme, and a good one to adhere to. I wonder if we should formalize it (i.e. target the stdlib to Python 2.1 where possible)? -Barry
This is emerging as a common theme, and a good one to adhere to. I wonder if we should formalize it (i.e. target the stdlib to Python 2.1 where possible)?
What would the point be? How many people are moving stdlib modules to previous releases? I think very few. I just added True/False to a whole bunch of places, and I'm sure with each new enticing feature it will be harder to keep the stdlib 2.1 compatible. I'm all for marking certain modules as "have to be backwards compatible" though -- e.g. sre. --Guido van Rossum (home page: http://www.python.org/~guido/)
"Barry A. Warsaw" wrote:
"MAL" == M <mal@lemburg.com> writes:
MAL> In general, I think it's a good idea to be very careful about MAL> introduce flashy new stuff to the std lib since it makes MAL> backporting fixes harder, e.g. using Python 2.1 features is MAL> OK, but not 2.2 features (if not absolutely necessary or only MAL> if they are easily separatable from the rest of the code).
This is emerging as a common theme, and a good one to adhere to. I wonder if we should formalize it (i.e. target the stdlib to Python 2.1 where possible)?
Guido van Rossum wrote:
What would the point be? How many people are moving stdlib modules to previous releases? I think very few.
The point is that in order to not make backporting patches for bug fix releases harder than necessariy, the code should not change in ways which would cause the backport to have to create a variant of the bug fix. This would introduce a branch and most probably new bugs.
I just added True/False to a whole bunch of places, and I'm sure with each new enticing feature it will be harder to keep the stdlib 2.1 compatible.
True and False are not hard to backport, but any new features which are not replicable in Python 2.1 should not go into the stdlib until we drop support for it. Then, if we do, Python 2.2 should become the new reference and so on.
I'm all for marking certain modules as "have to be backwards compatible" though -- e.g. sre.
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
True and False are not hard to backport, but any new features which are not replicable in Python 2.1 should not go into the stdlib until we drop support for it. Then, if we do, Python 2.2 should become the new reference and so on.
I think that puts the priorities backwards. If we can't develop the stdlib beyond what's supported by 2.1 we might as well stop developing. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
True and False are not hard to backport, but any new features which are not replicable in Python 2.1 should not go into the stdlib until we drop support for it. Then, if we do, Python 2.2 should become the new reference and so on.
I think that puts the priorities backwards. If we can't develop the stdlib beyond what's supported by 2.1 we might as well stop developing.
Huh ? It's not as if Python 2.1 doesn't offer you any means to implement whatever is needed in the standard lib. Most things don't require using bleeding edge language features which give 2.1/2.2 bug fix champions a hard time. Just to clarify: I'm talking about Python 2.1 language features here. I'm not requesting to stop working on the standard lib, if that's what you're reading. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
[MAL]
True and False are not hard to backport, but any new features which are not replicable in Python 2.1 should not go into the stdlib until we drop support for it. Then, if we do, Python 2.2 should become the new reference and so on.
[GvR]
I think that puts the priorities backwards. If we can't develop the stdlib beyond what's supported by 2.1 we might as well stop developing.
[MAL]
Huh ? It's not as if Python 2.1 doesn't offer you any means to implement whatever is needed in the standard lib. Most things don't require using bleeding edge language features which give 2.1/2.2 bug fix champions a hard time.
Just to clarify: I'm talking about Python 2.1 language features here. I'm not requesting to stop working on the standard lib, if that's what you're reading.
I understand you perfectly, and I disagree. If some code in a stdlib module can be written clearer or more efficiently by using a feature in 2.2 or 2.3, I don't see why we shouldn't use that feature, *unless* it's a module that is specifically marked to be exempt (like SRE). I won't start adding iterators and generators, nested scopes, new-style classes and so on just to make maintenance harder, but when writing new code or when revising existing code, we should use the features that make sense. Those features were all added because they improve the language's usability. Requiring the entire stdlib to be backwards compatible with 2.1 would be too difficult to do (and it's too late already). --Guido van Rossum (home page: http://www.python.org/~guido/)
[Barry A. Warsaw]
This is emerging as a common theme, and a good one to adhere to. I wonder if we should formalize it (i.e. target the stdlib to Python 2.1 where possible)?
-1. Using new features in the CVS libraries and tools is the only way we have to evaluate their usefulness, effectiveness, buginess and x-platform brittleness in anything approaching widely deployed code.
participants (11)
-
Aahz -
akuchlin＠mems-exchange.org -
barry＠zope.com -
Fred L. Drake, Jr. -
Guido van Rossum -
Jeremy Hylton -
M.-A. Lemburg -
martin＠v.loewis.de -
Neal Norwitz -
Skip Montanaro -
Tim Peters