-
-
Notifications
You must be signed in to change notification settings - Fork 118
Implement support for PEP 764 (inline typed dictionaries) #579
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
Conversation
# Setting correct module is necessary to make typed dict classes pickleable. | ||
ns['__module__'] = module | ||
ns = {'__annotations__': dict(fields)} | ||
module = _caller(depth=3) |
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 think it would be great to have _caller()
match the upstream, in particular having python/cpython#99520. Let me know and I'll send a separate PR.
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.
Yes, please do! Seems like it would have to be version-guarded.
c26d37d
to
09bfecc
Compare
I only just picked up on the fact that the PEP uses the term inlined TypeDict; somehow I've been reading that as inline TypedDict this whole time (possible because that's the term the mypy extension used?). The term makes sense to me when I think about it, but admittedly when I was toying with this locally and saw |
"Inlined" does read wrong to me, I'd also expect that to have something to do with function inlining. "Inline" or "anonymous" seems better. (Sorry no review of the code yet.) |
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.
a couple of high-level comments!
extra_items=NoExtraItems, | ||
**kwargs | ||
): | ||
class TypedDict(metaclass=_TypedDictMeta): |
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 suppose it's necessary to make TypedDict
a class so that you can subscript it? What about making it an instance of a _SpecialForm
subclass, similar to how Annotated
is implemented in CPython?
I doubt there's much difference between the two in terms of the user-facing behaviour, but conceptually it sort-of feels "wrong" for TypedDict
to be a class. You use TypedDict
to create types; it is not in itself a type; calling TypedDict
does not create an "instance of TypedDict
"; x: TypedDict
is an invalid type annotation; etc.
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'll give it a try.
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 opened #580 to compare both.
I think this is a good point, I'll switch to inline in the PEP document. |
Closing as #579 seems to be the approach we'll stick to. |
Fixes #572.
As discussed in the PEP thread, I've tried implementing inlined typed dictionaries as instances of a new
InlinedTypedDict
class, that would look like:But I don't think it is worth the effort:
__mro_entries__
onInlinedTypedDict
to allow subclassing inlined TDs. To be compatible with the existing logic in_TypedDictMeta.__new__
, we would most likely need to create an inner "real" TypedDict class matching theInlinedTypedDict
instance.InlinedTypedDict.__init__()
is simpler as it is guaranteed to not have base classes, logic is still duplicated in two places.Having
"<inlined TypedDict>"
as a__name__
might be considered as a slightly ugly implementation detail, but considering the above it is worth the trade-off.