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

Jacob Rus jacobolus at gmail.com
Sun Aug 2 08:37:18 CEST 2009

Jacob Rus wrote:
> Brett Cannon wrote:
>> Jacob Rus wrote:
>>> At the very least, I
>>> think some changes can be made to this code without altering its basic
>>> function, which would clean up the actual mime types it returns,
>>> comment the exceptions to Apache and explain why they're there, and
>>> make the code flow understandable to someone reading the code.
>> That all sounds reasonable.
> Okay, as a start, I did a simple code cleanup that I think fixes some
> potential bugs (any code using its own instance of the MimeTypes class
> should now be insulated from other same-process users of the module),
> chops out 80 or 90 lines, removes some redundant code paths, clarifies
> some of the micro level behavior of some chunks of code, adds a bit
> more to the docstring at the top of the file, and makes the program
> flow somewhat clearer … *without* changing the semantics of the module
> or its included list of MIME types.

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), and makes the
behavior of the code much clearer, I think, by making it very obvious
how the singleton instance is actually working.

Additionally, this version brings the lazy loading of Apache
mime.types files to every MimeTypes instance, and makes the
read_mime_types() function behave as expected (only getting the
mapping from an apache mime.types file rather than including some
extra types as the current code does).

In this version, tests would want to call the _init_singleton()
function to reset to defaults.


To reiterate: this should still behave identically to the current
module in all reasonable conditions. I still haven't made any changes
to the set of MIME types included in the file, or the behavior of the
module. Some such changes should be made as well, but the changes so
far should be relatively uncontroversial, I hope.

Jacob Rus

More information about the Python-Dev mailing list