GeezerVison is showing github.com — NamedTupleInterface · Issue #431 · python/typing
DescriptionHello, I already wrote on python-ideas group, I frequently am in need to have abstract access to the NamedTuple API, here a very simple exapmple:
from typing import NamedTupleType
def test(
arguments: NamedTupleType
) -> NamedTupleType:
return SomeType(**NamedTupleType._asdict) At the moment I have two hotfix:
Overload the namedtuple factory, but somewhat breaking my IDE or creating a fake namedtuple but both of them are hacks.
If my proposal get accepted I'm willingly to do the coding part :)
Thanks Activityilevkivskyi commented on May 16, 2017 Sorry, but it is still not clear what exactly do you need. If you just want to annotate a function parameter so that arbitrary named tuple can be passed there, then this will be solved by protocols, see #417 and PEP 544 (there are links to implementations for mypy and typeshed). For example something like this:
T = TypeVar('T', bound='NamedTupleProto')
class NamedTupleProto(Protocol):
_source: str
_fields: Tuple[str]
def _asdict(self) -> Dict[str, Any]: ...
@classmethod
def _make(cls: Type[T], iterable: Iterable[Any], *,
new: Any = None, len: int = None) -> T: ...
def __getitem__(self, item: int) -> Any: ...
def f(arg: NamedTupleProto) -> Dict[str, Any]:
arg[0]
return arg._asdict()
class A(NamedTuple):
a: int
class B(NamedTuple):
b: int
x: A
y: B
f(x) # OK
f(y) # OKIf you need only some part of the named tuple API, you could define a much simpler protocol.
EDIT: If you need the full named tuple API, then NamedTupleProto should also subclass Sequence (to pull also __len__, __iter__, etc) and declare few other methods (like _replace). gvanrossum commented on May 16, 2017 Is there a workaround we can use before that PEP is ready? Or is Any the
closest we can get without protocols?
…
On May 16, 2017 2:30 AM, "Ivan Levkivskyi" ***@***.***> wrote:
Sorry, but it is still not clear what exactly do you need. If you just
want to annotate a function parameter so that arbitrary named tuple can be
passed there, then this will be solved by protocols, see #417
< #417> and PEP 544 (there are links
to implementations for mypy and typeshed). For example something like
this:
T = TypeVar('T', bound='NamedTupleProto')
class NamedTupleProto(Protocol):
_source: str
_fields: Tuple[str]
def _asdict(self) -> Dict[str, Any]: ...
@classmethod
def _make(cls: Type[T], iterable: Iterable[Any], *,
new: Any = None, len: int = None) -> T: ...
def __getitem__(self, item: int) -> Any: ...
def f(arg: NamedTupleProto) -> Dict[str, Any]:
arg[0]
return arg._asdict()
class A(NamedTuple):
a: intclass B(NamedTuple):
b: int
x: A
y: B
f(x) # OK
f(y) # OK
If you need only some part of the named tuple API, you could define a much
simpler protocol.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
< #431 (comment)>, or mute
the thread
< https://github.com/notifications/unsubscribe-auth/ACwrMgybTgGVUKtr_8lDkkZ7ad4hV5Fvks5r6Wy7gaJpZM4NbwsB>
.
zauddelig commented on May 16, 2017 I fear we are comparing an elephant and an ant here.. Anyway to require an user to define an implicit protocol to describe a core library interface does not make a lot of sense.
At the moment I use various workarounds depending on the project, like creating the ABC myself and register my namedtuples manually, or use Any.
What I want to archive is not hard conceptually, NamedTupleType would be used exactly like typing.Tuple, but exposing the NamedTuple API as well. Out of the obvious it would also be a nice place to document namedtuples API incode, and it would probably make the life easier to code checker when accessing namedtuples' public methods . gvanrossum commented on May 16, 2017
What I want to archive is not hard conceptually
OK, submit a PR and maybe we'll merge it. ilevkivskyi commented on May 16, 2017
What I want to archive is not hard conceptually
Note that implementing this in typing can be easy, but implementing this in mypy could be much harder. IIUC, essentially, you want a structural subtyping check, which would be just reimplementing protocols for a particular case (you could avoid this by injecting a "fake" nominal supertype during the semantic analysis of named tuples, but this could have other potential problems).
In any case, as Guido mentioned, PRs are welcome. zauddelig commented on May 18, 2017 Okey dokey, I'll work on it during the weekend :)
@ilevkivski I actually was planning of doing that (injection) anyhow let's see. JukkaL commented on May 18, 2017 @ilevkivskyi It may make sense to have NamedTupleProto also define __getattr__, for consistency with __getitem__.
@zauddelig If something like NamedTupleProto is enough for you, you can just define this protocol once in some shared utility module and reuse it everywhere you need it. You can even publish it as a package on PyPI, and if it seems like many users find it useful, we can consider adding it to typing or mypy_extensions. Generally we are reluctant to add a feature (even a simple one) based on a request by a single user, especially if there is a workaround in sight that seems reasonable. Otherwise the static typing APIs will soon become very large and hard to learn, which is something we want to avoid. Each feature has a learning cost associated with it -- even if nobody needs some feature, most users will have to learn enough about the feature to at least be able to decide that it is something that they actually don't need. ilevkivskyi commented on May 18, 2017 @JukkaL
It may make sense to have NamedTupleProto also define __getattr__, for consistency with __getitem__.
Probably. TBH I just picked some random attributes to illustrate the idea, but I rather think this is not the case where "one size fits all". At least it is not completely clear to me what is the "named tuple API". mitar commented on Sep 17, 2017
Generally we are reluctant to add a feature (even a simple one) based on a request by a single user, especially if there is a workaround in sight that seems reasonable.
I think there are at least three users until now who were surprised by this, see also python/mypy#3915.
I think especially because in 3.6 NamedTuples have this nice class syntax. It then really looks like class and so it is surprising that one cannot just use it as a type. vnmabus commented on Jul 26, 2021
How can one access the _fields attribute from the namedtuple class itself instead of an instance of it? This protocol does not allow that, and using ClassVar does not seem to typecheck for me (maybe because _fields is read only somehow?). srittau commented on Nov 4, 2021 If this issue is still open, I think it should be reported to bugs.python.org. sobolevn commented on Nov 4, 2021 Related unmerged mypy PR: python/mypy#11162
It allows to write:
def deserialize_named_tuple(arg: NamedTuple) -> Dict[str, Any]:
return arg._asdict()
Point = namedtuple('Point', ['x', 'y'])
Person = NamedTuple('Person', [('name', str), ('age', int)])
deserialize_named_tuple(Point(x=1, y=2)) # ok
deserialize_named_tuple(Person(name='Nikita', age=18)) # ok
deserialize_named_tuple((1, 2))
# Argument 1 to "deserialize_named_tuple" has incompatible type "Tuple[int, int]"; expected "NamedTuple"Friendly ping to @JukkaL and @ilevkivskyi 😉
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|