On 04/09/16 11:57, Chris Angelico wrote:
On Sun, Sep 4, 2016 at 8:52 PM, Mark Shannon <m...@hotpy.org> wrote:
The key difference is in placement.
PEP 484 style
variable = value # annotation

Which reads to me as if the annotation refers to the value.
PEP 526
variable: annotation = value

Which reads very much as if the annotation refers to the variable.
That is a change in terms of semantics and a change for the worse, in terms
of expressibility.

So what you have is actually a change in *implication* (since the PEP
doesn't stipulate semantics); and the old way (the comment) implies
something contrary to the semantics of at least one of the type
checkers that uses it (MyPy).
Do we really want to make a major, irrevocable change to the language just because MyPy does something? MyPy is very far from complete (it doesn't even support Optional types yet).

Are there any current type checkers that
actually do associate that with the value? That is, to have "variable
= func() # str" indicate the same type check as "def func() -> str"?
If not, this is a strong argument in favour of the PEP, since it would
synchronize the syntax with the current best-of-breed checkers.
I believe pytype uses value, rather the variable, tracking. It is thus more precise. Of course, it is more of an inferencer than a checker. We (semmle.com) do precise value tracking to infer a lot of "type" errors in unannotated code (as the vast majority of Python code is).

It would be a real shame if PEP 526 mandates against checkers doing as good as job as possible. Forcing all uses of a variable to have the same type is a major and, IMO crippling, limitation.

E.g.
def foo(x:Optional[int])->int:
    if x is None:
       return -1
    return x + 1

If the type of the *variable* 'x' is Optional[int] then 'return x + 1' doesn't type check. If the type of the *parameter* 'x' is Optional[int] then a checker can readily verify the above code.

I want a checker to check my code and, with minimal annotations, give me confidence that my code is correct.


Cheers,
Mark.


ChrisA
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to