Support typing for NamedTuple unpacked variables

[oidualc]

Currently when a variable is unpacked from a typed NamedTuple, it's type is Any.
It would be nice if the type could be detected as it happens using the dot notation.
Example:

from typing import NamedTuple

class Employee(NamedTuple):
    name: str
    id: int

employee = Employee("Guido", 1)

employee.name  # (variable) name: str
employee.id  # (variable) id: int

(name, id) = employee  # (variable) name: Any, (variable) id: Any

[erictraut]

Thanks for the suggestion. It turns out that I implemented this support last week, and it will be included in the next version of Pylance. See microsoft/pyright#907 for more details.

[jakebailey]

This issue has been fixed in version 2020.8.2, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#202082-20-august-2020

[Kein]

Is it possible to implement type check for short syntax?

Entry = NamedTuple("Entry", size=int, offset=int, numSubs=int, subs=int, hasValue=bool)

This will report Entry.size as type: Any

[erictraut]

Pylance supports this documented form:

Entry = NamedTuple(
    "Entry",
    {
        ("size", int),
        ("offset", int),
        ("numSubs", int),
        ("subs", int),
        ("hasValue", bool),
    },
)

Or the variant documented in PEP 526:

class Entry(NamedTuple):
    size: int
    offset: int
    numSubs: int
    subs: int
    hasValue: bool

[Kein]

Pylance supports this documented form:

Entry = NamedTuple(
    "Entry",
    {
        ("size", int),
        ("offset", int),
        ("numSubs", int),
        ("subs", int),
        ("hasValue", bool),
    },
)

This does not work, it still reports size as any.

The class approach works but it is too verbose and OOP for 3 lines of code and the type that isnt reusable outside of that context.

[erictraut]

Apologies. It's supposed to be a list, not a dictionary.

Entry = NamedTuple(
    "Entry",
    [
        ("size", int),
        ("offset", int),
        ("numSubs", int),
        ("subs", int),
        ("hasValue", bool),
    ],
)

And you need to instantiate it:

a = Entry(3, 4, 5, 6, True)
a.size

[Kein]

And you need to instantiate it:

Ah, I see, so that's why it failed, I was populating it a bit differently. A warning for that when type checking enabled would be nice but I believe it is out of scope for Pylance. Thanks.

[Kein]

Is there any particular reason type annotations for anonymous tuples are not supported?
I would rather prefer:

(var, var2, var) = struct.unpack('<3I', data) # type: (int, int int)

then

var1 = 0 # type: int
var2 = 0 # type: int
var3 = 0 # type: int
(var, var2, var3) = struct.unpack('<3I', data)

[erictraut]

Old-style type annotations in comments were never documented in any PEP or the Python specification. They grew up organically and were eventually replaced by language syntax in Python 3.3 and 3.6. Pylance does support a few simple forms of these old-time comment forms, but we don't plan to add any more at this point. You should use the official language syntax for type annotations.

[gvanrossum]

Old-style type annotations in comments were never documented in any PEP or the Python specification. They grew up organically and were eventually replaced by language syntax in Python 3.3 and 3.6. Pylance does support a few simple forms of these old-time comment forms, but we don't plan to add any more at this point. You should use the official language syntax for type annotations.

Well, there's this: https://www.python.org/dev/peps/pep-0484/#id41

But I agree that we should encourage annotations for everything except # type: ignore.

[Kein]

Old-style type annotations in comments were never documented in any PEP or the Python specification. They grew up organically and were eventually replaced by language syntax in Python 3.3 and 3.6. Pylance does support a few simple forms of these old-time comment forms, but we don't plan to add any more at this point. You should use the official language syntax for type annotations.

So what about Python 2.x and very early 3.x that only basically support #type: T->T hints? I understand you dont want to actively support these, but is there any reason to completely abandon backwards compatibility with 2.x?

[erictraut]

Pylance doesn't support Python 2.x. If you need to maintain Python 2.x compatibility in your source base, the JEDI language server is available for your use.

[gvanrossum]

Another approach would be to specify mypy as the linter.