[Python-ideas] Optional static typing -- the crossroads

[Guido van Rossum]

On Fri, Aug 15, 2014 at 12:24 PM, Łukasz Langa <lukasz at langa.pl> wrote:

> On Aug 15, 2014, at 8:17 AM, Guido van Rossum <guido at python.org> wrote:
>
> You can probably come up with a notation for first-class variable
> annotations, e.g.
>
>     x: Sequence[int] = []
>
> Yes, that syntax is out of scope for now, though, right? If I understand
> your reasoning behind choosing Mypy’s function annotation syntax, we don’t
> want to create programs that require Python 3.5+ just to be parsed.
>

That's stronger than I meant it. The List<T> proposal would completely
prevent the new typing syntax from being backported. Having to refrain from
adding types for variables (or being required to use the inferior "magic
comment" syntax) is a much smaller burden.


> If we were to introduce first-class variable typing, yes, the syntax you
> propose is what I also had in mind.
>

It might be a separate PEP.

>  The value might be optional. The question is though, would the type
> (Sequence[int]) be stored anyway? Also, in a class body, does it define a
> class var or an instance var (or doesn't it matter?).
>
>
> I wouldn’t change the current behaviour:
>
> class C:
>   cls_member: str = ‘on the class’
>
>   def __init__(self):
>     self.obj_member: str = ‘on the instance'
>     self.cls_member = 2   # that’s the real question: type error or an
> instance member?
>
> For that last case, even though it’s currently valid Python, my intuition
> tells me for Mypy to treat it as an error.
>

I disagree -- it's a very common idiom to set (immutable) default values on
the class for what is meant to be an instance variable. This is why I
called it out as a question we need to answer.

> Does this need a 'var' keyword to be ambiguous?
>
> I fail to see any additional value provided by such keyword. What would
> stop people from doing
>
> var i = 1
>
> I don’t think we want to end up with that.
>

In a different world it could be used to address the issue of typos going
unnoticed, but I think it would be too big a departure from current PYthon
practice.


> I propose to disallow declaring multiple variables in this style, since
> it's hard to decide whether the comma should bind tighter than the '=' sign
> (as in assignments) or less tight (as in function headings).
>
>
> Right. I wonder if we even need this. For lines that use multiple
> assignment just for brevity, they can switch to multiple lines for typing.
> For common cases like:
>
> host, port = origin.rsplit(‘:’, 1)
> successful, errors = query_the_world(hostnames)
>
> I think the types can be easily inferred (assuming rsplit and
> query_the_world are annotated).
>

Sure. It's just that people would be expecting it to work based on
generalizations from other forms -- it's just that if you generalize from
argument lists you end up with something different than when you generalize
from assignment. I think it's reasonable to disallow

  a, b: Tuple[int, float] = 42, 3.14

but to allow

  (a, b): Tuple[int, float] = (42, 3.14)


>  While we’re at slaying dragons, I’ll also silently make str non-iterable
>> so that we can use Sequence[str] meaningfully from now on… How about that?
>>
>
> I hope you meant that as a joke. We missed our chance for that one with
> Python 3.0. We must live with it.
>
>
> Yes, that was obviously just a joke. By the way, is the PEP number 4000
> free? Asking for a friend.
>

I totally missed the joke. :-(

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/8bc0cfdb/attachment.html>