``` import mimetypes print(mimetypes.guess_type('foo.manifest')) mimetypes.add_type('text/plain', 'manifest') print(mimetypes.guess_type('foo.manifest')) ``` results in: ``` ('application/x-ms-manifest', None) ('application/x-ms-manifest', None) ``` I (mistakenly) expected the latter print to give me "('text/plain', None)". It doesn't because I should have prepended a . to the second add_type argument. I think add_type should error out when given an extension without a dot-prefix, because it's extremely unlikely that code that does so is behaving as intended with the current implementation. (At the very least, documentation should be updated to make this expectation clearer.)
I think we should deprecate calling `add_type` with an empty `ext`, as I don't think it's a feature, more a side effect of the current implementation. But as some may use it like a feature, I asked the current PR to emit a warning, to not break the current implementations. To be able to simplify in the future, why not deprecating empty `ext` so we can remove it in a few versions?
I just found a case where the empty mime type is actually usefull, it's in Lib/http/server.py: extensions_map = mimetypes.types_map.copy() extensions_map.update({ '': 'application/octet-stream', # Default '.py': 'text/plain', '.c': 'text/plain', '.h': 'text/plain', }) It does *not* uses add_type, but demos the fact that the empty type may be usefull from time to time, maybe don't warn and don't deprecate it at all.
