Alas, we didn't think of struct sequences when we designed PEP 484. It seems they are a hybrid of Tuple and NamedTuple; both of these are currently special-cased in mypy in ways that cannot easily be combined.

Do you really need anonymous fields?

I see an example in typeshed/stdlib/3/os/__init__.pyi (in github.com/python/typeshed), for stat_result. It defines names for all the fields, plus a __getitem__() method that indicates that indexing returns an int. This doesn't help if anonymous fields could have different types, not does it teach the type checker about the number of anonymous fields.

--Guido

On Wed, Aug 7, 2019 at 1:51 AM Christian Tismer <tismer@stackless.com> wrote:

Hi all,

Ok, I am about to implement generation of such structures
automatically using the struct sequence concept.

One more question:
------------------

Struct sequences are not yet members of the typing types.
I would like to add that, because a major use case is also to
show nice .pyi files with all the functions and types.

* namedtuple has made the transition to NamedTuple

* What would I need to do that for StructSequence as well?

Things get also a bit more complicated since struct sequence
objects can contain unnamed fields.

Any advice would be appreciated, I am no typing expert (yet :-)

cheers -- Chris

On 30.07.19 17:10, Guido van Rossum wrote:
> I think I have to agree with Petr. Define explicit type names.
>
> On Tue, Jul 30, 2019 at 2:45 AM Paul Moore <p.f.moore@gmail.com
> <mailto:p.f.moore@gmail.com>> wrote:
>
> On Tue, 30 Jul 2019 at 09:33, Christian Tismer <tismer@stackless.com
> <mailto:tismer@stackless.com>> wrote:
> > >>> typing.NamedTuple("__f", x=int, y=int)
> > <class '__main__.__f'>
> > >>> typing.NamedTuple("__f", x=int, y=int) is typing.NamedTuple("__f",
> > x=int, y=int)
> > False
>
> This appears to go right back to collections.namedtuple:
>
> >>> from collections import namedtuple
> >>> n1 = namedtuple('f', ['a', 'b', 'c'])
> >>> n2 = namedtuple('f', ['a', 'b', 'c'])
> >>> n1 is n2
> False
>
> I found that surprising, as I expected the named tuple type to be
> cached based on the declared name 'f'. But it's been that way forever
> so obviously my intuition here is wrong. But maybe it would be useful
> for this case if there *was* a way to base named tuple identity off
> the name/fields? It could be as simple as caching the results:
>
> >>> from functools import lru_cache
> >>> cached_namedtuple = lru_cache(None)(namedtuple)
> >>> n1 = cached_namedtuple('f', ('a', 'b', 'c')) # A tuple rather
> than a list of field names, as lists aren't hashable
> >>> n2 = cached_namedtuple('f', ('a', 'b', 'c'))
> >>> n1 is n2
> True
>
> Paul
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> /Pronouns: he/him/his //(why is my pronoun here?)/
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GIFRTFWPEGKZ33PTW63YXKGXHHAQJ35I/
>

--
Christian Tismer :^) tismer@stackless.com
Software Consulting : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776 fax +49 (30) 700143-0023