Hunting for deprecated modules. * Deprecated in 2.1: TERMIOS.py, whrandom.py. * Deprecated in 2.2: mpz module, statcache module. There are also various 2.2-deprecated methods in the email package; Barry can decide if he wants to bother with them or not. * Deprecated in 2.3: xreadlines module, rotor module, rfc822 module, mimetools module, mimify module, MimeWriter module. Only rotor and xreadlines raise a DeprecationWarning in 2.3, so they're the only candidates for removal. The other modules, except for xreadlines, are marked as deprecated in PEP4; should we make them trigger DeprecationWarnings? My proposal: * Remove TERMIOS, mpz, statcache, xreadlines, rotor. * Make rfc822 raise PendingDeprecationWarning (so nothing will happen in 2.4 unless you have -Wa) * Make mimetools, mimify, Mimewrite raise DeprecationWarnings. (This is the part I'm least sure about; comments from people who know about these modules would be appreciated. Should they raise Pending instead?) I don't know what to do about whrandom, if anything; remove it? Leave it for 2.5? suggestions? --amk
I don't know what to do about whrandom, if anything; remove it? Leave it for 2.5? suggestions?
From PEP4: "#This module has been documented as obsolete since Python 2.1, but listing in this PEP was neglected. The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that."
Though the module is useless, I think we have to follow the PEP. Raymond
[Andrew]
I don't know what to do about whrandom, if anything; remove it? Leave it for 2.5? suggestions?
[Raymond]
From PEP4: "#This module has been documented as obsolete since Python 2.1, but listing in this PEP was neglected. The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that."
Though the module is useless, I think we have to follow the PEP.
whrandom should definitely get a DeprecationWarning for 2.4. 2.3 final was released in July of 2003, and it's already a year after.
A.M. Kuchling wrote:
* Make rfc822 raise PendingDeprecationWarning (so nothing will happen in 2.4 unless you have -Wa)
A few bits and pieces in the stdlib still use bits from rfc822. They all mostly look pretty shallow, except:
* Make mimetools, mimify, Mimewrite raise DeprecationWarnings. (This is the part I'm least sure about; comments from people who know about these modules would be appreciated. Should they raise Pending instead?)
mimetools.Message subclasses rfc822.Message, and mimetools.Message is
used extensively in the std lib.
--
Anthony Baxter
On Sat, 2004-08-07 at 16:57, A.M. Kuchling wrote:
Hunting for deprecated modules.
* Deprecated in 2.1: TERMIOS.py, whrandom.py. * Deprecated in 2.2: mpz module, statcache module.
There are also various 2.2-deprecated methods in the email package; Barry can decide if he wants to bother with them or not.
I'll probably remove those. We're bumping the email package's own version number to 3.
My proposal: * Remove TERMIOS, mpz, statcache, xreadlines, rotor. * Make rfc822 raise PendingDeprecationWarning (so nothing will happen in 2.4 unless you have -Wa)
+1
* Make mimetools, mimify, Mimewrite raise DeprecationWarnings. (This is the part I'm least sure about; comments from people who know about these modules would be appreciated. Should they raise Pending instead?)
DeprecationWarnings on mimify and MIMEWriter. Not sure atm, what to do about mimetools, but it's clearly destined for death. -Barry
Barry Warsaw wrote:
I'll probably remove those. We're bumping the email package's own version number to 3.
The AddlistClass in email is marked as deprecated, but is deprecated in favour of a class in rfc822!
* Make mimetools, mimify, Mimewrite raise DeprecationWarnings. (This is the part I'm least sure about; comments from people who know about these modules would be appreciated. Should they raise Pending instead?)
DeprecationWarnings on mimify and MIMEWriter. Not sure atm, what to do about mimetools, but it's clearly destined for death.
mimetools is used in a number of other modules - including urllib
httplib cgi and urllib2. Worse, they use mimetools.Message, which
is a subclass of rfc822.Message. urllib/urllib2's addinfourl.info()
is documented as returning a mimetools.Message().
I mentioned this on IRC yesterday - I do not think we should put in
a PendingDeprecationWarning (or a DeprecationWarning) for anything
until we've stripped it's usage from the stdlib. If we can't be
bothered to update our code to no longer use the code we want to
dump, it hardly seems fair to expect our users to do so. I'd go
so far as to say that this should be explicitly stated in the PEP.
I also think that a "final" release should not issue PDWs from
the test suite (with the obvious exception of code that is explicitly
testing the PDWed feature.
--
Anthony Baxter
On Sun, Aug 08, 2004 at 05:59:22PM +1000, Anthony Baxter wrote:
The AddlistClass in email is marked as deprecated, but is deprecated in favour of a class in rfc822!
Maybe deprecating rfc822 simply isn't a worthwhile goal? Anyway, here's a revised action list: * Remove TERMIOS, mpz, statcache, xreadlines, rotor. (Unchanged from my earlier proposal.) These modules have raised DeprecationWarning for a while, but only rotor is listed in PEP 4. I'll add them to the PEP in any event; is not being listed sufficient grounds for delaying their removal to 2.5? (I would say we don't need to wait until 2.5; they've been raising DeprecationWarnings for a long time, so users should be well aware the modules' days are numbered.) * Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now. * Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them. --amk
On Mon, Aug 09, 2004, A.M. Kuchling wrote:
Maybe deprecating rfc822 simply isn't a worthwhile goal?
Anyway, here's a revised action list:
* Remove TERMIOS, mpz, statcache, xreadlines, rotor. (Unchanged from my earlier proposal.)
These modules have raised DeprecationWarning for a while, but only rotor is listed in PEP 4. I'll add them to the PEP in any event; is not being listed sufficient grounds for delaying their removal to 2.5?
(I would say we don't need to wait until 2.5; they've been raising DeprecationWarnings for a long time, so users should be well aware the modules' days are numbered.)
* Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now.
* Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them.
What about DeprecationWarning for whrandom? (Not that I care personally.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com
The following list of suggestions has been sitting around since the beginning of August? If not, I'll proceed with the actions described below. --amk On Mon, Aug 09, 2004 at 05:15:17PM -0400, A.M. Kuchling wrote:
Anyway, here's a revised action list:
* Remove TERMIOS, mpz, statcache, xreadlines, rotor. (Unchanged from my earlier proposal.)
These modules have raised DeprecationWarning for a while, but only rotor is listed in PEP 4. I'll add them to the PEP in any event; is not being listed sufficient grounds for delaying their removal to 2.5?
(I would say we don't need to wait until 2.5; they've been raising DeprecationWarnings for a long time, so users should be well aware the modules' days are numbered.)
* Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now.
* Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them.
* Remove TERMIOS, mpz, statcache, xreadlines, rotor. (Unchanged from my earlier proposal.)
These modules have raised DeprecationWarning for a while, but only rotor is listed in PEP 4. I'll add them to the PEP in any event; is not being listed sufficient grounds for delaying their removal to 2.5?
(I would say we don't need to wait until 2.5; they've been raising DeprecationWarnings for a long time, so users should be well aware the modules' days are numbered.)
* Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now.
* Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them.
All +1 from me. (I still haven't started using the new email package, so I'm reluctant to see my beloved rfc822.py disappearing in the future; but I trust its fate is sealed, and I'm happy it gets an extension. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) Ask me about gmail.
On Mon, Aug 30, 2004 at 12:57:37PM -0700, Guido van Rossum wrote:
(I still haven't started using the new email package, so I'm reluctant to see my beloved rfc822.py disappearing in the future; but I trust its fate is sealed, and I'm happy it gets an extension. :-)
I don't know if you followed the subsequent thread, but removing rfc822 is going to take quite a while. A 2.5 problem... Removing statcache.py breaks two modules in Lib/lib-old, cmpcache.py and dircmp.py. What should be done: rewrite them to use os.stat instead of statcache, or just delete them? The files in lib-old were last touched six weeks ago when Tim cleaned up the whitespace; before that they hadn't been touched since 2001 at the latest.. Wow, before Tim's whitespace n11n, lib-old/newdir.py was last touched in August 1994. 10 years ago! --amk
amk> Removing statcache.py breaks two modules in Lib/lib-old, amk> cmpcache.py and dircmp.py. What should be done: rewrite them to amk> use os.stat instead of statcache, or just delete them? Why not migrate statcache.py to lib-old? Skip
On Tue, Aug 31, 2004 at 08:29:38AM -0500, Skip Montanaro wrote:
Why not migrate statcache.py to lib-old?
I don't really see the point of lib-old these days; we now have a better mechanism for marking modules as outdated. If people prefer moving statcache to lib-old, fine; personally, I'd just delete all of lib-old, too. --amk
>> Why not migrate statcache.py to lib-old? amk> I don't really see the point of lib-old these days; I thought lib-old was just a convenience so people using defunct modules could resurrect them more easily. (I realize people can also grab them from the CVS attic.) Skip
On Mon, 2004-08-30 at 15:23, A.M. Kuchling wrote:
* Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now.
* Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them.
+1 on these from me, as the only realistic option. -Barry
Barry Warsaw wrote:
On Mon, 2004-08-30 at 15:23, A.M. Kuchling wrote:
* Leave rfc822, mimetools alone; the stdlib will have to avoid their use first, and I'm not going to do that right now.
* Make mimify, MimeWriter raise DeprecationWarnings; nothing in the stdlib uses them.
+1 on these from me, as the only realistic option.
I'd like to have a really serious effort to make sure we can DW the
first group for 2.5. In particular, the mimetools.Message class is
used for a whole pile of different protocols (anything with rfc2822
style Header: Value lines). To me, it doesn't make much sense that
this lives in a module called 'mimetools'.
But maybe that's just me.
Anthony
--
Anthony Baxter
On Tue, 2004-08-31 at 11:23, Anthony Baxter wrote:
I'd like to have a really serious effort to make sure we can DW the first group for 2.5. In particular, the mimetools.Message class is used for a whole pile of different protocols (anything with rfc2822 style Header: Value lines). To me, it doesn't make much sense that this lives in a module called 'mimetools'.
But maybe that's just me.
Naw, I'm with you. I'd hoped to get farther along for all this stuff for 2.4, but I didn't expect to get so distracted <292 winks>. :) -Barry
participants (8)
-
A.M. Kuchling -
Aahz -
Anthony Baxter -
Barry Warsaw -
Guido van Rossum -
Raymond Hettinger -
Skip Montanaro -
Tim Peters