-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Allow NewType subclassing NewType. #3465
Conversation
Use case: type hierarchy of IDs, all of which are integers at runtime, but we want to type-check distinctions between e.g. "id of User" and "id of Media", while still allowing some functions to take "any ID" (which is still a more specific type than "any integer").
Well, I don't think the spec of NewType in PEP 484 supports this. Also, does it work at runtime? (I suppose it would since NewType('x', int) just returns int.) The use case sounds reasonable though. @ilevkivskyi Thoughts? |
Yeah, PEP 484 says that the second arg to |
(And yes, it works fine at runtime.) |
I like the idea. This will require a small update to PEP 484. This indeed works at runtime (even for runtime introspection tools). For example: Id = NewType('Id', int)
UserId = NewType('UserId', Id)
assert UserId.__supertype__.__name__ == 'Id'
assert UserId.__supertype__.__supertype__ is int |
OK, it does make sense, and go ahead with the PEP 484 update. |
OK, here is the PR python/peps#271 with the PEP 484 update. |
See discussion in python/mypy#3465
* master: (23 commits) Make return type of open() more precise (python#3477) Add test cases that delete a file during incremental checking (python#3461) Parse each format-string component separately (python#3390) Don't warn about returning Any if it is a proper subtype of the return type (python#3473) Add __setattr__ support (python#3451) Remove bundled lib-typing (python#3337) Move version of extensions to post-release (python#3348) Fix None slice bounds with strict-optional (python#3445) Allow NewType subclassing NewType. (python#3465) Add console scripts (python#3074) Fix 'variance' label. Change label for variance section to just 'variance' (python#3429) Better error message for invalid package names passed to mypy (python#3447) Fix last character cut in html-report if file does not end with newline (python#3466) Print pytest output as it happens (python#3463) Add mypy roadmap (python#3460) Add flag to avoid interpreting arguments with a default of None as Optional (python#3248) Add type checking plugin support for functions (python#3299) Mismatch of inferred type and return type note (python#3428) Sync typeshed (python#3449) ...
It has become possible to create a ``NewType`` from an existing ``NewType``, see python/mypy#3465 and python/peps#271. This is a small update to the documentation as a concequence of the above change.
Use case: type hierarchy of IDs, all of which are integers at runtime, but we
want to type-check distinctions between e.g. "id of User" and "id of Media",
while still allowing some functions to take "any ID" (which is still a more
specific type than "any integer").
This seems to work as expected, it only requires removing an explicit guard
against it. Is there a reason to prohibit it? I didn't find any specific rationale
in the issue (#1284) or commit. @JukkaL raised it as a question in
#1284 (comment)
but it wasn't ever discussed further.