-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
ChainMap
has wrong or unintuitive type after #6042
#8430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@hauntsaninja wrote
|
Fixes problems reported by mypy. Related: python/typeshed#8430
Fixes problems reported by mypy. Related typeshed issue: python/typeshed#8430 PR #53: #53
This was done in commit 3cbe472 to avoid a type warning that the second and next arguments to ChainMap are not mutable. Related Mypy issue: python/typeshed#8430. When we use `!relative` in MkDocs configuration, the config then contains a MkDocs path placeholder instance, which itself contains a reference to the MkDocs config, and all its plugins, including mkdocstrings, and all its objects, etc. Upon deepcopying this huge object tree, deepcopy fails on mkdocstrings private attribute `_inv_futures`, which contains `Future` and therefore `thread.RLock` objects, which are not serializable. This failed with a `TypeError: cannot pickle '_thread.RLock` objects`. So in this commit we stop deep-copying everything just to avoid a Mypy warning, and instead we add a type-ignore comment. If Mypy fixes this someday, we'll simply get a new warning that the comment is unused.
I just discovered I believe that the most troublesome part with this suggestion is that the I was intrigued by the idea of an immutable variant, so I gave it a shot. It does require (safe) type ignores if built on top of the stdlib I made two variations: one that is in fact still mutable but protects its member mappings from mutation. And one that is immutable itself. The benefit of the latter is that it can confidently implement the
|
Fixes problems reported by mypy. Related typeshed issue: python/typeshed#8430 PR #53: mkdocstrings/python#53
This was done in commit 3cbe472e98be1174966bdbda34d6a6fb2336f2cf to avoid a type warning that the second and next arguments to ChainMap are not mutable. Related Mypy issue: python/typeshed#8430. When we use `!relative` in MkDocs configuration, the config then contains a MkDocs path placeholder instance, which itself contains a reference to the MkDocs config, and all its plugins, including mkdocstrings, and all its objects, etc. Upon deepcopying this huge object tree, deepcopy fails on mkdocstrings private attribute `_inv_futures`, which contains `Future` and therefore `thread.RLock` objects, which are not serializable. This failed with a `TypeError: cannot pickle '_thread.RLock` objects`. So in this commit we stop deep-copying everything just to avoid a Mypy warning, and instead we add a type-ignore comment. If Mypy fixes this someday, we'll simply get a new warning that the comment is unused.
#6042/#6044 gives me new mypy complaints on my code base.
ChainMap
only ever writes to the first mapping inmaps
. That's my understanding. For exampleChainMap({}, defaults)
is a typical use-case where the user gets a dict-like and cannot mutate the defaults. That's the typical stacking property of the ChainMap, you only ever mutate the top, most recent mapping.From my understanding:
I don't think we can have correct hints for the
maps
member, andnew_child
of course expects a mutable mapping because iirc it is exactly the next top most thing on the stack.Originally posted by @kaste in #6042 (comment)
(I started this as a comment on the closed issue but closed issues don't move and I got initial supportive feedback on my comment from @hauntsaninja.)
The text was updated successfully, but these errors were encountered: