[Python-ideas] Proposal: Use mypy syntax for function annotations

[Terry Reedy]

On 8/14/2014 11:21 AM, Andrew Barnert wrote:
> On Aug 14, 2014, at 7:37, Ryan Gonzalez
> <rymg19 at gmail.com
> <mailto:rymg19 at gmail.com>> wrote:
>
>>     On 8/13/2014 3:44 PM, Guido van Rossum wrote:
>
>>     Now consider an extended version (after Lucas).
>>
>>     def fib(n, a, b):
>>         i = 0
>>         while i <= n:
>>             print(i,a)
>>             i += 1
>>             a, b = b, a+b
>>
>>     The only requirement of a, b is that they be addable. Any numbers
>>     should be allowed, as in fib(10, 1, 1+1j), but so should fib(5,
>>     '0', '1'). Addable would be approximated from below by
>>     Union(Number, str).
>>
>>
>> Unless MyPy added some sort of type classes...
>
> By "type classes", do you mean this in the Haskell sense, or do you mean
> classes used just for typing--whether more granular ABCs (like an
> Addable which both Number and AnyStr and probably inherit) or typing.py
> type specifiers (like an Addable defined as Union(Number, AnyStr)?

What I like is the idea of protocol based types, as in
Andrey Vlasovskikh's slide 26
http://blog.pirx.ru/media/files/2013/python-optional-typing/#26

class Addable(Protocol):
     @abstractmethod
     def __add__(self, other):
         pass

Even this does not capture the actual requirement that a and b be 
addable together, in that order.  Addable_together is inherently a pair 
concept.  Syntactically, that could be handled by passing a pair.

def fib(n:Comparable_to_int, pair:Addable_together) -> Type resulting 
from pair:

However, the actual Python rules for Addable_together are rather 
complex. A static type checker for this would be extremely difficult to 
write. The best dynamic type checker is to try and let Python say no by 
raising.

> It's also worth noting that the idea that this function should take a
> Number or a str seems way off.

As written, it *does* take any pair that can be repeatedly added together.

> It's questionable whether it should accept str,

I recently read Douglas Hofstadler's Fluid Concepts and Creative 
Analogies: Computer Models of the Fundamental Mechanisms of Thought. In 
the first chapter he discussed puzzles like: A series begins 0, 1, 01, 
101, ..., what is the next item.  He started with number sequences and 
moved on to digit string sequences like the above, where the digit 
strings are *not* interpreted as number. Generic functions and 
duck-typing encourages this sort of creative thinking.

 > but if it does, shouldn't it also accept bytes,
 > bytearray, and other string-like types?

Of course. A descriptive type should not invalidate anything that is 
allowed.

 > What about sequences? And meanwhile,
> whether or not it accepts str, it should probably accept np.ndarray and
> other types of element-wise adding types.

The function above already does accept such.

> If you create an Addable type,
> it has to define, globally, which of those counts as addable, but
> different functions will have different definitions that make sense.

A single arg having .__(r)add__ is trivial.  The real difficultly is 
expressing *addable to each other* and relating the result type to the 
types of the members of the pair.




-- 
Terry Jan Reedy