-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
selftype in namedtuple methods #2408
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
I'm going to revert this. Here's a problem we encountered that was caused by this PR: from typing import NamedTuple
NT = NamedTuple('NT', [('x', str)])
class C:
def __init__(self) -> None:
self.a = NT('')
def foo(self) -> None:
self.a = self.a._replace(x='') # Error here The error is
|
Ouch. Sorry. |
Well, [a-z]{4} happens! Feel free to fix at your leisure. (We do actually
care about this feature, so your efforts are much appreciated!)
|
Reverts #2408 This appears to have a bug; see my comment to the PR for an explanation.
My fault is not the bug, but the fact that this PR has no reasonable tests. I should be more careful. This whole method of constructing a new Instance inside the code is volatile. I'd rather have a superclass and a magic parameter. Something like: class NamedTuple(metaclass=NamedTupleMeta):
def _replace(self: T, **kwargs: __FIELDS__=...) -> T: ... It should probably be somehow internal to mypy. It will also make the implementation of the new-style syntax trivial. |
Yeah, I should have realized that this requires new tests and asked you to add some. I'm not sure I understand your code snippet -- where should that go? What is |
It should go in typeshed, or probably "shadow" typeshed (do we have such thing?). One problem with namedtuple currently is that the signature of
(In general, I am trying to figure out a "language" that will allow expressing common patterns in metaclasses, decorators and other type-manipulating constructs. selftype is helpful, but I think we need more. The intention is not to be an |
What is "shadow" typeshed?
Anyways, I have to take responsibility: last week our team decided that
before landing "significant" changes to mypy or typeshed we should test the
change against our main internal repos, and I did not do that for this
change.
|
I meant somewhere we can put signatures that are mypy-specific, possibly experimental. |
Hm, we don't have that. We have something like that for typing.py additions
but not for typeshed additions. Possibly we can add them to the regular
typeshed under `if MYPY`.
|
(Reopening #2408 after the revert #2414. This fixes parts of #2090) This PR does three things: Fix the handling of TupleType (pass original_type recursively) Fix the handling of TypeType (avoid ad-hoc buggy special casing) Make NamedTuple's _replace() and _make() return selftype, serving as test case for (1) and (2) As a consequence of (1), some error messages are changed, as exemplified in check-isinstance.test. I think it's better now, but if it isn't, perhaps we should separate original_type and report_type as discussed in #2193.
Fix one item from #2090.