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

[Guido van Rossum]

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

> On Aug 14, 2014, at 4:56 PM, Guido van Rossum <guido at python.org> wrote:
>
> There's also a variant of (1) that Łukasz Langa would like to see -- use
> the syntactic position of function annotations but using a custom syntax
> (e.g. one similar to the pytypedecl syntax) that isn't evaluated at
> function-definition time. This would have to use "from __future__ import
> <something>" for backward compatibility. I'm skeptical about this though;
> it is only slightly more elegant than mypy, and it would open the
> floodgates of unconstrained language design.
>
>
> I see the decision has been made. For the curious, the design would be as
> close as possible to PEP 3107. The biggest wins would be first-class
> annotations for variables (supported in Mypy as comments) and support for
> forward-references without the need to fall back to strings.
>

You can probably come up with a notation for first-class variable
annotations, e.g.

    x: Sequence[int] = []

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?).

Does this need a 'var' keyword to be ambiguous?

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).


>
> I’m also not a fan of the square brackets for generics (those brackets
> mean lookup!) but a BDFL once said that “language evolution is the art of
> compromise” and one cannot disagree with that.
>
>
> So there you have it. I am picking the mypy family and I hope we can start
> focusing on specific improvements to mypy.
>
>
> Alright! That sounds good. With the syntax mostly out of the way, the next
> issue to handle is the typing module. dict, MutableMapping, and now Dict…
> One step too far. We should be able to re-use ABCs for that, e.g. to add
> support for union types and generics. Lots of decisions ahead (covariance,
> casting, multiple dispatch, etc.) but we’ll get there.
>
> The typing module as aliases for the updated ABCs sounds like a fair
> compromise, although I’m worried about the details of that approach (for
> starters: we need to bundle the new ABCMeta to support union types but
> having both implementations at runtime feels very wrong). Moreover, with
> dynamic type registration and duck typing isinstance(), there will be
> challenges to cover. I’m happy to go and slay that dragon.
>
> As a side note, I’m happy you’re willing to agree on str | None. This
> reads really well and is concise enough to not require aliasing to be
> usable.
>
> 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.

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