Repository navigation
annotationlib: namespace can be non-dict #132426
Description
Activity
- added a commit that references this issue
on Apr 12, 2025 However, I now realize that this is a major issue since there might be a conflict between the
Mappingsubtype's own annotations and the annotations it contains as a mapping for another type's namespace.Shouldn't we separate
get_annotate_functionintoget_annotate_functionandget_namespace_annotations? Or maybe add a keywordget_annotate_function(obj, *, is_namespace: bool)?- pinned this issue
on Apr 12, 2025 - unpinned this issue
on Apr 12, 2025 Good point! I think what I'd like to do is drop
get_annotate_functioncompletely (it's now equivalent to a simplegetattrcall and doesn't need to be a function) and add a new functionget_annotate_from_class_namespace.Your proposed change is a bit dubious because "mapping" at the C level means something a little different (it basically just checks for the
mp_subscrslot). Not sure if that will cause practical problems but better to be safe.However, I now realize that this is a major issue since there might be a conflict between the Mapping subtype's own annotations and the annotations it contains as a mapping for another type's namespace.
Since instances no longer have accessible annotations by default, this will only be a problem in exotic cases like a Mapping that is also an instance of
type. But again, better to be safe.- added a commit that references this issue
on May 4, 2025 Fixed by #132490, thanks for the report!
Reacted by eliegoudout- added a commit that references this issue
on May 4, 2025
Hello!
I think the following, made so that
get_annotate_functionis usable in metaclasses'__new__, should check forMappingsince__prepare__can provide any mapping (see picture from PEP3115.cpython/Lib/annotationlib.py
Line 630 in a81232c
Linked PRs
get_annotate_functionvs. mapping namespaces #132427