Author ncoghlan
Recipients eric.araujo, jab, jrus, ncoghlan, r.david.murray
Date 2014-01-25.03:41:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1390621312.61.0.143592228175.issue6626@psf.upfronthosting.co.za>
In-reply-to
Content
Note that I still believe there are substantial improvements that could be made without a wholesale rewrite of the module that poses significant backwards compatibility risks (just improving the documentation regarding how the list of types is populated could likely help some users, as would updating the default list we use if we can't retrieve one from the environment).

Alternatively, even if we can't get anyone interested in such a refactoring task, it may be feasible to introduce an improved mimetypes handling interface that is easier to maintain and keep up to date, again without risking backwards compatibility issues for users of the current module.

Some potentially relevant links for anyone wanting to investigate improving the standard library's MIME type support:

The discussions with Jacob in Rietveld regarding his original approach: https://codereview.appspot.com/107042

PyPI libraries:

https://pypi.python.org/pypi/mimeparse/
https://pypi.python.org/pypi/mime
https://pypi.python.org/pypi/zope.mimetype
https://pypi.python.org/pypi/Products.MimetypesRegistry (Jacob pointed this one out above)

The various PyPI wrappers around libmagic and the *nix "file" utility are also of potential interest for research purposes (but aren't especially useful on Windows, where those tools are significantly less likely to be available).
History
Date User Action Args
2014-01-25 03:41:52ncoghlansetrecipients: + ncoghlan, eric.araujo, r.david.murray, jab, jrus
2014-01-25 03:41:52ncoghlansetmessageid: <1390621312.61.0.143592228175.issue6626@psf.upfronthosting.co.za>
2014-01-25 03:41:52ncoghlanlinkissue6626 messages
2014-01-25 03:41:49ncoghlancreate