Hi Guido, If a C++ function already has a return value, plus some primitive pointer variables that need to be moved into the result in Python, then we have the case with a first, single unnamed field. Only one such field can exist.
I'm not sure if that case exists in the ~25000 Qt5 functions, but in that case, I think to give that single field the name "unnamed" or maybe better "result". Thank you very much for pointing me to that example! Cheers -- Chris On 08.08.19 06:41, Guido van Rossum wrote: > 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 <http://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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On 2019年7月30日 at 09:33, Christian Tismer > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > 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> > <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 -- [email protected] > <mailto:[email protected]> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/[email protected]/message/GIFRTFWPEGKZ33PTW63YXKGXHHAQJ35I/ > > > > > -- > Christian Tismer :^) [email protected] > <mailto:[email protected]> > 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 > > > > -- > --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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/QZ44KHLLNL54ZCHEAQ5WBWCOV7AU2HGW/ > -- Christian Tismer :^) [email protected] 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 _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/I4LGR6Q6QJ5L4AIWI4BRMXUTXEGIMYJ2/