[issue34938] Fix mimetype.init() to account for from import

Ashley Whetter report at bugs.python.org
Mon Oct 28 14:00:37 EDT 2019


Ashley Whetter <ashley at awhetter.co.uk> added the comment:

Maybe updating the dictionaries isn't right at all.
I think if you were experienced enough you would have the intuition that mutable attributes like this are not going to change in your local scope if you import them into it. But relying on this knowledge makes it difficult for newer users. Plus we all make mistakes ;) So a note in the docs sounds like a good idea to me.

I think `init` does rebuild when `files` is `None` (https://github.com/python/cpython/blob/edb172a87296d9359593a23cd9a09f5867ea1f0e/Lib/mimetypes.py#L350) but it's not clear to me whether rebuilding should include any additional types registered with `add_type`. At the moment it says `the mapping will be added to the official MIME types`, but I think an additional note that this means that it will persist after subsequent calls to `init` would make that clear.

As for importing `init` into the local scope, I think ideally we wouldn't use `global` at all. We should be able to make `init` import `mimetypes` locally and explicitly access attributes on the module?
Another option is we make the module attributes accessible through a module level `__getattr__` which gets the attributes off of the global `Mimetypes` object stored in `mimetypes._db`. But that would still require usage of a `global _db`.

----------
nosy: +AWhetter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34938>
_______________________________________


More information about the Python-bugs-list mailing list