[Python-Dev] standard library mimetypes module pathologically broken?

Jacob Rus jacobolus at gmail.com
Sun Aug 2 22:17:45 CEST 2009

Robert Lehmann wrote:
> Jacob Rus wrote:
>> Here is a somewhat more substantively changed version. This one does
>> away with the 'inited' flag and the 'init' function, which might be
>> impossible given that their documented (though I would be extremely
>> surprised if anyone calls them in third-party code)
> [snip]
> There seem to be quite a bunch of high-profile third-party modules
> relying on this interface, eg. Zope, Plone, TurboGears, and CherryPy. See
> http://www.google.com/codesearch?q=mimetypes.init+lang%3Apython for a
> more thorough listing.
> Given that most of them aren't ported to Python 3 yet, I guess, changing
> the semantics in 3.x seems not-too-bad to me.

Ooh, okay.  Well I guess we can’t get rid of those then!

Michael Foord wrote:
> Please post the patches to the Python bug tracker:

I made a new issue on the bug tracker,
<http://bugs.python.org/issue6626>, and added a new patch which should
hopefully be fairly reasonable.  I still haven't addressed the issue
of which MIME types should be included by default, and how precisely
the logic should work for setting those up. But again, hopefully this
at least makes it clear what the code is trying to do, so that it's
relatively readable for someone trying to use the module. (For
instance, so they'll be warned off of using init() and breaking
each-other's code)

Paul Moore wrote:
> The patch you post should also patch the test suite to use your
> replacement initialisation function where needed (if you didn't
> already do that).

Done. The tests still pass, though to be honest this test suite isn't
really testing any edge cases.

Jacob Rus

More information about the Python-Dev mailing list