I see a new check. Should I write a news entry for this? Or will the committer?

@davidkhess It's easier for us if you create the news entry because if a core dev decides to merge this they can edit the file easily through GitHub's web UI while having to add a file is much more burdensome.

News entry added.

@bitdancer, anything I can do to help this along?

@brettcannon @bitdancer, anything I can do to help this along?

I'm willing to resolve the conflict but I don't want to waste my time if this PR is never going to be merged.

Unfortunately I don't know this module well enough to feel comfortable reviewing it. I would try pinging the issue to ask if someone could review it.

Pinged.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

The merge conflict does need to be fixed, and it looks like it'll be a bit of work to figure out exactly what needs merging.

I'm making the requested changes now.

@auvipy @csabella good to go.

@serhiy-storchaka and @zooba, the merge conflicts have been resolved. I know this was approved last year, but I wanted to make sure you were still OK with it before merging. Thanks!

Thanks @davidkhess for the PR, and @zooba for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

Sorry @davidkhess and @zooba, I had trouble checking out the 3.8 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 9fc720e5e4f772598013ea48a3f0d22b2b6b04fa 3.8

GH-14375 is a backport of this pull request to the 3.8 branch.

This change has resulted in a difference in behaviour from previous versions of Python in that even when specifying files as a parameter to init(), the known files are loaded, which is not the case in previous versions. This causes problems when an application wishes to use the mimetypes database with an internal-only mapping of mimetypes, to work around inconsistencies with mimetypes in the known files list (which can vary between systems).

Unfortunately this change wasn't documented in the changelog either, nor in the docstring comments, so it can only be found by examining the commit history for the code in cpython.

Would it be appropriate to add another kwarg to init() indicating that knownfiles are to be ignored/excluded from the DB initialization?

@adeadman posted a message inline as a reply to mine at 9fc720e#r45794801

In essence this fixe was supposed to bring in a deterministic behaviour and actually had the complete opposite effect. I still consider this a regression. I stopped using mimetypes for now as it is useless as it is now.

Could you please open a new bug report? Comments on closed PRs tend to get lost.

@adeadman @tiran let me create a new issue #93417