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 The Compiler
Recipients The Compiler, ammar2, dhess, steve.dower, toonn, xtreak
Date 2019-11-18.13:29:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Ah, I think I see what's happening now.

Before that commit, when doing "mt = mimetypes.MimeTypes()", its self.types_map is populated as follows:

- Its __init__ method calls the mimetypes.init() function.
- That then reads all the files in mimetypes.knownfiles into a temporary MimeTypes object
- The resulting types_map is saved as a module global (mimetypes.types_map).
- The __init__ of our "mt" object continues and picks up all the types from that global types_map.

After the change, instead this happens:

- Its __init__ method calls the mimetypes.init() function.
- Like above, mimetypes.init() populates mimetypes.types_map
- However, MimeTypes.__init__ now uses _types_map_default instead of the (now reassigned) types_map, i.e. it never reads the entries from knownfiles.

In other words, it only picks up the hardcoded types in the module, but never reads the files it's (according to the documentation) supposed to read - thus the difference between using "mimetypes.guess_type('E01.mkv')" (which uses the correctly initialized global object) and using "mimetypes.MimeTypes().guess_type('E01.mkv')" (which doesn't know about mkv, as it's defined in one of the mimes.types files, not hardcoded in the module).

As a workaround, this results in the same behavior as before:

mt = mimetypes.MimeTypes()
for fn in mimetypes.knownfiles:
    if os.path.isfile(fn):
Date User Action Args
2019-11-18 13:29:10The Compilersetrecipients: + The Compiler, steve.dower, ammar2, dhess, xtreak, toonn
2019-11-18 13:29:10The Compilersetmessageid: <>
2019-11-18 13:29:10The Compilerlinkissue38656 messages
2019-11-18 13:29:09The Compilercreate