Support structural subtyping for named tuples

[ilevkivskyi]

This appeared in python/typing#427

We can consider allowing code like this:

class Point(NamedTuple):
    x: int
    y: int
class LabeledPoint(NamedTuple):
    x: int
    y: int
    label: str

def fun(p: Point): ...
fun(LabeledPoint(1, 2, 'test'))  # OK

This seems to be type safe and will be relatively easy to implement after protocols land.

[gvanrossum]

If you really want this, can you make it an option in PEP 544? Personally I think it would require an extra marker class, since otherwise if fun() contained assert isinstance(p, Point) it would be problematic.

[ilevkivskyi]

If you really want this, can you make it an option in PEP 544?

Not that I really want this, but I have seen this "feature request" at least twice, so that we can at least consider this.

Concerning the PEP, I would rather add a common section about NamedTuple and TypedDict, they are quite similar and the latter already behaves structurally. What do you think?

I think it would require an extra marker class, since otherwise if fun() contained assert isinstance(p, Point) it would be problematic.

Again, maybe we can just have a class keyword?

class Point(NamedTuple, structural=True):
    x: int
    y: int

[gvanrossum]

I suppose I caused one of those feature requests myself. :-)

As we have now clearly demonstrated, this is one of those features that a requester can easily think is simple to implement, but there are actually many traps in any possible solution.

I'm not so sure that NamedTuple and TypedDict are really all that similar (except they are both attempts to handle outdated patterns in a statically-typed world). Now that we have a design for dataclasses, even the current limited OO version of NamedTuple seems already a dead end and I sort of wish we hadn't gone there (extra sad because I originally wanted it). In any case I expect NamedTuple and TypedDict to take different development paths (though we may want to curb our enthusiasm for OO TypedDict definitions given what we're going through for NamedTuple).

I propose to stop proposing any new additions to NamedTuple (but TypedDict is something we want to develop at least to the point where it's actually useful for Dropbox).

[ilevkivskyi]

Now that we have a design for dataclasses, even the current limited OO version of NamedTuple seems already a dead end and I sort of wish we hadn't gone there (extra sad because I originally wanted it) [...] I propose to stop proposing any new additions to NamedTuple

NamedTuple class syntax was anyway an interesting experience that was not in vain I believe. Now we have much more input for the dataclasses.

(but TypedDict is something we want to develop at least to the point where it's actually useful for Dropbox).

Maybe then it makes sense to add a section about TypedDict to PEP 544, since TypedDict behaves structurally?

[gvanrossum]

Actually I think TypedDict needs its own PEP if we want it to be more than a mypy-specific extension.

[ilevkivskyi]

Actually I think TypedDict needs its own PEP if we want it to be more than a mypy-specific extension.

OK, less work for me :-) Then this issue can be closed I think. I others don't agree, then they can re-open.