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 <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>> 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>>> 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>>> 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-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> 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 _______________________________________________ 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/I4LGR6Q6...
-- 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