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 <tismer@stackless.com <mailto:tismer@stackless.com>> 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 <tismer@stackless.com <mailto:tismer@stackless.com> > <mailto:tismer@stackless.com <mailto: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> > <mailto:p.f.moore@gmail.com <mailto:p.f.moore@gmail.com>> > > <mailto:p.f.moore@gmail.com <mailto:p.f.moore@gmail.com> <mailto: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> <mailto:tismer@stackless.com <mailto:tismer@stackless.com>> > > <mailto:tismer@stackless.com <mailto:tismer@stackless.com> <mailto: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> <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 -- python-dev@python.org <mailto:python-dev@python.org> > <mailto:python-dev@python.org <mailto:python-dev@python.org>> > > To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org> > <mailto:python-dev-leave@python.org <mailto: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/GIFRTFWP... > > > > > -- > Christian Tismer :^) tismer@stackless.com <mailto:tismer@stackless.com> > <mailto:tismer@stackless.com <mailto: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 > > > > -- > --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 -- python-dev@python.org <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-leave@python.org <mailto: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/QZ44KHLL... >
-- Christian Tismer :^) tismer@stackless.com <mailto: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
-- --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/D3LTF3V2...
-- 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