This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jrus
Recipients jrus
Date 2009-08-02.21:52:37
SpamBayes Score 2.562367e-11
Marked as misclassified No
Message-id <1249249964.7.0.434792884046.issue6626@psf.upfronthosting.co.za>
In-reply-to
Content
Here is a list I generated of all the current Apache mime.types:

I would just as soon include this in the python standard library, either 
just the Apache file as is, or even these python object literals (maybe 
in a file outside of mimetypes.py), and then *not* import from Apache 
files by default, to cut down on external dependencies. There are 
several alternate MIME types for various types that should be added to 
this list (in earlier positions so they only are used in the type -> 
extension map).

The only issue is that some users may have added to their Apache 
mime.types files for the sake of getting mailman or other python 
programs to do what they want. So I'm not entirely sure to what extent 
we should be 100% backwards compatible in such edge cases. 

My personal opinion is that the 'strict' option is unnecessary and 
should be set to do nothing, because users are more likely to want the 
predictable behavior where an unorthodox type gives back the proper 
extension, than the behavior where their code fails unless they pass a 
flag in: I don't see any reason for a user to want a 'type doesn't 
exist' message back for non-registered types. This isn't a "test for 
IANA registration" module.
History
Date User Action Args
2009-08-02 21:52:45jrussetrecipients: + jrus
2009-08-02 21:52:44jrussetmessageid: <1249249964.7.0.434792884046.issue6626@psf.upfronthosting.co.za>
2009-08-02 21:52:43jruslinkissue6626 messages
2009-08-02 21:52:43jruscreate