[Python-ideas] Trial balloon: adding variable type declarations in support of PEP 484

[Daniel Moisset]

On Mon, Aug 1, 2016 at 10:31 PM, Guido van Rossum <guido at python.org> wrote:

>
> Second, when these occur in a class body, they can define either class
> variables or instance variables. Do we need to be able to specify
> which?
>

I'd say that if I have a class C with a class variable cv, instance
variable iv, a good type checking system should detect:

C.cv # ok
C.iv # error!
C().iv # ok

which is something that PEP484 doesn't clarify much (and mypy flags all 3
as valid)

So in short, I think it is relevant to specify differently class vs
instance vars.

Suppose we wanted to add types to the latter. Would we write this as
>
> a, b: int, str = 0, ''
>
> or as
>
> a: int, b: str = 0, ''
>
> ??? Personally I think neither is acceptable, and we should just write it
> as
>
> a: int = 0
> b: str = ''
>
> but this is a slight step back from
>
> a, b = 0, ''   # type: (int, str)
>

I'm not specially fond of the «# type: (int, str)». It works ok for 2
variables, but for more it is hard to mentally "align" the variable names
to the type names, for example in:

kind, text, start, end, line = token # type: (int, str, Tuple[int, int],
Tuple[int, int], str)

it's not easy to quickly answer "what is the type of 'end' here?". So I
wouldn't miss that notation a lot if it went away

Given that, I'm happier with both the 2-line solution and the second
one-liner, which both keep the types closer to the names. But given that as
you mentioned:

kind: int, text:str, start: Tuple[int, int], end: Tuple[int, int], line:
str = token

looks a bit misleading (looks more like an assignment to token), perhaps it
would avoid errors to accpt as valid only:

(kind: int, text:str, start: Tuple[int, int], end: Tuple[int, int], line:
str) = token

other possibility if you really love the current mypy syntax (perhaps both
could be valid):

(kind, text, start, end, line):(int, str, Tuple[int, int], Tuple[int, int],
str) = token

I don't like that one very much, but perhaps it inspires ideas on someone
here.

Other places to think about are:

* Multiple assignment (Chris mentioned these)
* loop variables (in a for statement, comprehensions, generator expressions)
* lambda arguments


-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160802/f4ae90c9/attachment.html>