[Python-Dev] Dealing with mimetools usage in the stdlib

[Brett Cannon]

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