Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
PEP 749: Add section on metaclasses #3847
PEP 749: Add section on metaclasses #3847
Changes from 1 commit
bc211ee
629a50b
bdd6198
ef781a5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do
type.__annotate__
andtype.__annotations__
still exist in this approach? (I don't believe they're needed, but best to be explicit)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that I don't think they'd be needed with this approach
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe they may be needed for non-heap types. I will experiment with this when I implement the idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the implicit mapping access also update the
cls.__dict__
entry? (thanks to the owner information passed to__set_name__
, it could).If it doesn't, the specification should be explicit that the underlying
dict
will be cached on the descriptor instance, so it can be added tocls.__dict__
later and any changes made via the descriptor's mapping API will still be visible.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a pure-Python proof of concept for the idea here: https://gist.github.com/AlexWaygood/29e386e092377fb2e288620df1765ed5
The PoC does not currently update the
__dict__
entry -- it just caches the materialized annotations internally in the descriptor instance -- but I think you're right that it could, potentially.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a sentence that makes my proposal more explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "classes" here mean all
type
instances? Or specifically heap types created with aclass
statement? What about the equivalent Python and C APIs?I suspect only types created via a
class
statement getting these descriptors implicitly will make the most sense, with static types and types created via the dynamic Python and C APIs getting__annotate__ = None
and__annotations__ = {}
if nothing else is specified in the supplied class dicts.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All classes that have >=1 class with annotations in their MRO must have
"__annotations__"
and"__annotate__"
keys in their class dictionaries under this proposal. Theoretically I think it would be fine to omit these keys from the class dictionary if you could reliably determine that no classes in the MRO have any annotations. I don't know if that's worth the complexity, though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or in the MRO of a metaclass.
I think you're right and this should apply to classes created through the
class
statement, and classes created in ways that may inherit from Python classes should simply set the fields to None and {}.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, yeah