-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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 747: Revised TypeForm specification #3929
PEP 747: Revised TypeForm specification #3929
Conversation
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
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.
Lots of great work here Eric! I've left some comments below.
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.
Thanks, this looks great.
My main area of concern is the mandated "dual evaluation", which feels inconsistent with how evaluation normally works. I would prefer to have behavior similar to what we do for TypedDict:
from typing import TypedDict
class TD(TypedDict):
a: int
x = {"a": 1}
reveal_type(x) # dict[str, int]
y: TD = {"a": 1}
reveal_type(y) # TD
So expressions are by default evaluated as they are now, but in a context where a TypeForm is expected (e.g., when assigning to a variable of type TypeForm), we infer a TypeForm type.
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.
The revised approach - using only the new "TypeForm interpretation" when an explicit TypeForm
annotation is used on the receiving variable/parameter - looks good. It avoids the "duality of types" seen before. It also appears to sidestep any reliance on an intersection type (&
) which avoids entangling with future work in that area of the type system. 👍
I've left one minor comment suggesting reinstating a code example to make some of the text more clear.
I'll make a post in discuss.python.org inviting further feedback on this PR shortly.
This is updated version of draft PEP 747. It attempts to clarify the terminology, and it changes the design to eliminate limitations and reduce edge cases and backward compatibility issues.
📚 Documentation preview 📚: https://pep-previews--3929.org.readthedocs.build/