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:34:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574084074.23.0.685434694682.issue38656@roundup.psfhosted.org>
In-reply-to
Content
Ah, I only saw dhess' comment after already submitting mine.

> By historical design, instantiating a MimeTypes class instance directly will not use host OS system mime type files.

Yet that wasn't what happened before that commit, and it's also not the behaviour which was (and is) documented - from https://docs.python.org/3.6/library/mimetypes.html#mimetypes.MimeTypes

    By default, it provides access to the same database as the rest of this module. The initial database is a copy of that provided by the module, and may be extended by loading additional mime.types-style files into the database using the read() or readfp() methods. The mapping dictionaries may also be cleared before loading additional data if the default data is not desired.

    The optional filenames parameter can be used to cause additional files to be loaded “on top” of the default database.

You might be right in that the new behaviour is in some way more correct - but it's wildly backwards-incompatible, and it's contrary to everything the documentation says.

I've only skimmed over bpo-4963 though - maybe I missing something?
History
Date User Action Args
2019-11-18 13:34:34The Compilersetrecipients: + The Compiler, steve.dower, ammar2, dhess, xtreak, toonn
2019-11-18 13:34:34The Compilersetmessageid: <1574084074.23.0.685434694682.issue38656@roundup.psfhosted.org>
2019-11-18 13:34:34The Compilerlinkissue38656 messages
2019-11-18 13:34:33The Compilercreate