Hi Ronald, sure, the tuple is usually not very interesting; people look it up once and use that info in the code.
But I think things can be made quite efficient and pretty at the same time. Such a return tuple could be hidden like the stat_result example that Guido mentioned: https://github.com/python/typeshed/blob/master/stdlib/3/os/__init__.pyi def stat(self, *, follow_symlinks: bool = ...) -> stat_result: ... The stat_result is a huge structure where you don't want to see much unless you are working with a stat_result. Other with common, repeating patterns like (x, y, width, height) or your examples: def getpoint(v: pointless) -> (int, int) def getvalue(v: someclass) -> (bool, int) would be at first sight def getpoint(v: pointless) -> getpoint_result def getvalue(v: someclass) -> getvalue_result But actually, a much nicer, speaking outcome would be written as the single function StructSequence(...) with arguments, producing: def getpoint(v: pointless) -> StructSequence(x=int, y=int) def getvalue(v: someclass) -> StructSequence(result=bool, val=int) That would have the nice effect of a very visible structure in the .pyi file. When you actually get such an object and look at it, then you have >>> getpoint(pointless()) getpoint_result(x=17, y=4) >>> getvalue(someclass()) getvalue_result(result=True, val=42)) And the "magic" function StructSequence would simply index a dict with the given argument tuple that gives the right struct sequence. This is always possible, since only names and types are involved in the lookup. Cheers -- Chris On 08.08.19 14:22, Ronald Oussoren wrote: > Chrisian, > > How would these namedtuple/structseq values be used? I have a similar > design with PyObjC: pass-by-reference “return” values are returned in a > tuple, e.g.: > > void getpoint(pointclass* v, int* x, int *y) => def get > point(v: pointless) -> (int, int) > BOOL getvalue(someclass* v, int* val) => def getvalue(v: > someclass) -> (bool, int) > > I rarely, if ever, see code that actually stores the return tuple as-is. > The return tuple is just deconstructed immediately, like “x, y = > getpoint(mypoint)”. > > Ronald > — > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ > >> On 8 Aug 2019, at 10:42, Christian Tismer <tis...@stackless.com >> <mailto:tis...@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 <tis...@stackless.com >>> <mailto:tis...@stackless.com> >>> <mailto:tis...@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.mo...@gmail.com >>>> <mailto:p.f.mo...@gmail.com> >>> <mailto:p.f.mo...@gmail.com> >>>> <mailto:p.f.mo...@gmail.com <mailto:p.f.mo...@gmail.com>>> wrote: >>>> >>>> On Tue, 30 Jul 2019 at 09:33, Christian Tismer >>> <tis...@stackless.com <mailto:tis...@stackless.com> >>> <mailto:tis...@stackless.com> >>>> <mailto:tis...@stackless.com <mailto:tis...@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> >>>> To unsubscribe send an email to python-dev-le...@python.org >>>> <mailto:python-dev-le...@python.org> >>> <mailto:python-dev-le...@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 :^) tis...@stackless.com >>> <mailto:tis...@stackless.com> >>> <mailto:tis...@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-le...@python.org >>> <mailto:python-dev-le...@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 :^) tis...@stackless.com >> <mailto:tis...@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 >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> <mailto:python-dev@python.org> >> To unsubscribe send an email to python-dev-le...@python.org >> <mailto:python-dev-le...@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/I4LGR6Q6QJ5L4AIWI4BRMXUTXEGIMYJ2/ > -- Christian Tismer :^) tis...@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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/ETAFIDB67C7PYPKMUEUSFFYD4X55PBBZ/
