selftype in namedtuple methods

[elazarg]

Fix one item from #2090.

[gvanrossum]

I'm going to revert this. Here's a problem we encountered that was caused by this PR:

fromtypingimportNamedTupleNT=NamedTuple('NT', [('x', str)])
classC:
def__init__(self) ->None:
self.a=NT('')
deffoo(self) ->None:
self.a=self.a._replace(x='') # Error here

The error is

__tmp__.py: note: In member "foo" of class "C":
__tmp__.py:7: error: Incompatible types in assignment (expression has type "__tmp__.NT", variable has type "NT")

[elazarg]

Ouch. Sorry.

[gvanrossum]

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!)

[elazarg]

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:

classNamedTuple(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.

[gvanrossum]

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 __FIELDS__?

[elazarg]

It should go in typeshed, or probably "shadow" typeshed (do we have such thing?).

One problem with namedtuple currently is that the signature of _replace and __init__ depends on the declared fields, thus requiring dedicated generating code inside mypy.

__FIELDS__ is a magic annotation that tells mypy to create a new method for the subclass, with the appropriate parameters (e.g. x: int = ..., y: str = ... if the new subclass has fields x : int and y : str).

(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 pyi-style interface, but more of a plugin. In the extreme, I was thinking about a very small subset of Python, or something similar to template-metaprogramming. I don't have any concrete suggestion so there's no need to reject it just yet :) )

[gvanrossum]

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.

[elazarg]

I meant somewhere we can put signatures that are mypy-specific, possibly experimental.

[gvanrossum]

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`.