[Python-ideas] Proposal to extend PEP 484 (gradual typing) to support Python 2.7

[Agustín Herranz Cecilia]

Hi!, I'd come to this thread late and by coincidence, but after read the 
whole thread I want to share some thoughts:

The main concern it's add a way to add some kind of gradual typing to 
python 2 code. Because it's working python2 code it can't use 
annotations and it can't be added in code, so a type comment is the way 
to go (independent of the convenience, or not, of having type annotation 
available on runtime).

Someone points that using a comment with the python3 annotation 
signature it's good to educate people on how to use annotations, I feel 
that's not the point, the point is to people get used to type hints. For 
this the same syntax must be used across different python versions, so 
'function type comments' must be available to use also in python 3 code, 
this also allow people who can't/won't use annotations to use type hinting.

For this, I don't believe that the section "Suggested syntax for Python 
2.7 and straddling code" added to PEP 484 is the correct way to go, the 
proper it's add type comments for functions, as a extension of the "Type 
comments" section or perhaps in a new PEP.

Some concerns that must be take into account to add function type comments:

- Using 'type comments' syntax of PEP484 a function signature should 
look like this:

def func(arg1, arg2):  # type: Callable[[int, int], int]
     """ Do something """
     return arg1 + arg2

- This easily becomes a long line so breaks PEP8 and linters would 
complain. So it need to define a way to put the type comment in another 
line. The type comment will be put In the line after or in the line 
before? Put in another line will be only available for function type 
comments or for other type comments too?

- With some kind of complex types the type comment surely become a long 
lint too, how the type comments will be break into different lines?

- GVR proposal includes some kind of syntactic sugar for function type 
comments (" # type: (t_arg1, t_arg2) -> t_ret "). I think it's good but 
this must be an alternative over typing module syntax (PEP484), not the 
preferred way (for people get used to typehints). Is this syntactic 
sugar compatible with generators? The type analyzers could be 
differentiate between a Callable and a Generator?

More concerns on type comments:

- As this is intended to gradual type python2 code to port it to python 
3 I think it's convenient to add some sort of import that only be used 
for type checking, and be only imported by the type analyzer, not the 
runtime. This could be achieve by prepending "#type: " to the normal 
import statement, something like:
     # type: import module
     # type: from package import module

- Also there must be addressed how it work on a python2 to python3 
environment as there are types with the same name, str for example, that 
works differently on each python version. If the code is for only one 
version uses the type names of that version. For 2/3 code types could be 
define with a "py2" prefix on a module that could be "py2types" having 
"py2str", for example, to mark things that be of python2 str type. 
Python 3 types will not have prefixes.


I hope this reasoning/ideas will be useful. Also I hope that I have been 
expressed good enough, English is not my mother tongue.

Agustín Herranz.