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?
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 <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>>> 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>>>
> 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 -- 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/GIFRTFWPEGKZ33PTW63YXKGXHHAQJ35I/
> >
>
>
> --
> 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/QZ44KHLLNL54ZCHEAQ5WBWCOV7AU2HGW/
>
--
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
--