On 8 Aug 2019, at 17:12, Christian Tismer <tismer@stackless.com> wrote:

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

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 ;-).

Ronald