Message91208
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. |
|
Date |
User |
Action |
Args |
2009-08-02 21:52:45 | jrus | set | recipients:
+ jrus |
2009-08-02 21:52:44 | jrus | set | messageid: <1249249964.7.0.434792884046.issue6626@psf.upfronthosting.co.za> |
2009-08-02 21:52:43 | jrus | link | issue6626 messages |
2009-08-02 21:52:43 | jrus | create | |
|