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 <anthony at interlink.com.au> It's never too late to have a happy childhood.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4