Hi Ronald,sure, the tuple is usually not very interesting; people look it uponce and use that info in the code.But I think things can be made quite efficient and pretty at thesame time. Such a return tuple could be hidden like the stat_resultexample 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 muchunless 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_resultBut actually, a much nicer, speaking outcome would be written asthe 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 inthe .pyi file. When you actually get such an object and look at it,then you have
But will you ever look at these objects, other then when exploring APIs in the REPL? As I wrote earlier the normal usage for a similar pattern in PyObjC is to always immediately deconstruct the tuple into its separate values.
BTW. I’m primarily trying to understand your use case because it is so similar to what I’m doing in PyObjC, and such understanding can lead to an improvement in PyObjC ;-).