Yes, that's what I mean. Probably retval or whatever people prefer would be adequate, with a special rule if that name is taken.
I think btw. that using StructSequence(somename=sometype, ..., ) that does a dict lookup is quite appealing. It returns a class like stat_result, but the function call shows its arguments (see answer to Ronald). Ciao -- Chris On 08.08.19 17:22, Guido van Rossum wrote: > OK, yes, having a convention for naming the anonymous field sounds like > the way to go. But presuming people will want to use it, and probably > know it from the C++ API, why not name it 'return_value' or 'result' or > 'retval' or something like that? > > On Thu, Aug 8, 2019 at 1:43 AM Christian Tismer <[email protected] > <mailto:[email protected]>> wrote: > > 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> > <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]> > > <mailto:[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]>> > > > <mailto:[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]>> > > > <mailto:[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> > > <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]> > > <mailto:[email protected] <mailto:[email protected]>> > > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > <mailto:[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]> > > <mailto:[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> > <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/QZ44KHLLNL54ZCHEAQ5WBWCOV7AU2HGW/ > > > > > -- > 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/D3LTF3V2IZLOY5CV4RXMCKO52BXBJZD6/ > -- 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/YTQZM5BCMG4IDXUE7YZL3M7BDSQLOC2Z/