When user lacks rights to read on of the mimetypes.knownfiles, mimetypes init() will throw PermissionError and library becomes unusable.

Reproduction steps:
# mkdir -p /etc/httpd/conf/
# touch /etc/httpd/conf/mime.types
# chmod a-r /etc/httpd/conf/mime.types
$ python
>>> import mimetypes
>>> mimetypes.init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/mimetypes.py", line 355, in init
    db.read(file)
  File "/usr/lib/python3.7/mimetypes.py", line 204, in read
    with open(filename, encoding='utf-8') as fp:
PermissionError: [Errno 13] Permission denied: '/etc/httpd/conf/mime.types'

The fix seems fairly obvious: replacing isfile check with try-catch statement for all OSErrors. Would you like to submit a pull request, Michał?

An exception report is a failure to finish but not a crash as meant here.

The current code requires all known files and any file explicitly passes to be readable.  The proposed simple change would make it OK if none of them are.  But is this really OK?

Is it really OK if known files are not readable?  Should they not be readable by all?

Removing the isfile call would allow directories to be passed through to db.readfp.  This might not be a good idea.  We would definitely have to think about what errors might be raised on different systems.

I think the try-except should be in init rather than db.read.  The latter can be called directly and I think a user explicitly passing an filename should be notified.  This comment actually also applies to files passed to init.

[Sidenote: the doc says that MimeTypes "provides an interface similar to the one of the mimetypes module."  The mimetypes.db used by mimetypes functions *is* a MimeTypes instance and the user can call db methods anything after init().]

Overall, I am not convinced that the current behavior is a bug, in which case this is an 'enhancement' request that changes the current API.  I am not at all a mimetypes expert, so I nosied a couple of email people who have worked on the module and should know more.

I haven't looked at this in detail, but here are my general thoughts: I think it would be reasonable to expect that the module would function even if the file permissions are screwed up, similar to how unix commands that try to read .netrc will (try to) function even if its permissions are wrong.  I would, however, expect the module to emit a warning in that case.  I'm of two minds about the behavior when the caller specifies filenames explicitly.  I could see that going either way, but I lean slightly toward making the behavior consistent.  While the programmer might appreciate the traceback, the user of the program would probably appreciate the "try to keep going" behavior, since the filenames provided will often be in the same class of "standard defaults" as the existing well known files are, just in the context of that particular application.  But like I said, that is just a lean, and I could go the other way on this as well :)

I haven't looked at the isflie issue, but it seems reasonable that if the path exists we should make sure it is a file before reading it...but perhaps readfp will effectively do that?  Write a test and see what happens :)

I don't know whether to call this change a bug fix or a feature, so I guess we'd default to feature unless someone can tilt the balance with an argument :)