[Python-Dev] Dealing with mimetools usage in the stdlib (original) (raw)

Brett Cannon brett at python.org
Mon Aug 11 08:10:20 CEST 2008

On Sat, Aug 9, 2008 at 11:52 PM, Adam Olsen <rhamph at gmail.com> wrote:

On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon <brett at python.org> wrote:

On my quest to remove warnings raised in 2.6 when Python is run with -3, the issue of dealing with mimetools has come up in terms of backwards-compatibility. For instance, in BaseHTTPServer, the headers attribute on BaseHTTPRequestHandler is an instance of mimetools.Message. But in 3.0 it is an instance of http.client.HTTPMessage.

So my question is, should 2.6 be changed to match 3.0, or should deprecation warnings for mimetools (and possibly other modules) just be silenced so as to not risk breaking backwards-compatibility? Just silence them. The warnings are an aid for finding bugs, not an excuse to create more bugs.

The problem I just realized with silencing them, though, is that the warning only occurs once at initial import, so if you silence the import in BaseHTTPServer but then import mimetools directly later on the DeprecationWarning won't come up from the later import. It's an unfortunate side-effect of caching imported modules in sys.modules. The only way around it is to either delete the module out of sys.modules so that subsequent imports will reload the module, or to come up with some modification to import that does some check for a deprecated flag or something and raises the proper deprecation with the specified message before returning the module (which I really don't see happening this late in the development cycle, but still might be a good idea to think through for 2.7/3.1)::

import sys if sys.py3kwarning: deprecated = "the mimetools module has been removed in Python 3.0"

Rest of module's code

-Brett

More information about the Python-Dev mailing list