[Python-ideas] Optional Static Typing -- the Python Way

[Guido van Rossum]

On Tue, Aug 19, 2014 at 6:27 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
[Agreeable musings about team size...]

Ultimately, my perspective is that Guido's proposal boils down to
> having a nice syntax where:
>
>     def myfunc(a : KindX, b: KindY, c: KindZ):
>         ...
>
> is the moral equivalent of:
>
>     def myfunc(a, b, c):
>         assert isinstance(a, KindX)
>         assert isinstance(b, KindY)
>         assert isinstance(c, KindZ)
>

Please no. The asserts affect runtime. The type declarations are for
linting, IDEs and docs. I don't want the difference to be swept under the
rug. I want it to be the key feature of the proposal.


> except done in a way that is more amenable to static analysis by
> looking at the compiled AST, rather than actually executing the code.
>

Ironically, mypy also understands isinstance() checks, using them as a kind
of implied "typecase" (though I don't know if it understands assert -- it
definitely understands "if isinstance(x, int): x = x**2".


> Calling it "optional static typing" is probably a bad idea, since the
> proposal isn't to change the type system itself - that will be just as
> dynamic as it always has been. "optional type assertions" is probably
> the most accurate, but then people may think it is *actually*
> translated to runtime checks as I show above, which it won't be.
>

I don't know what you mean by "accurate".


> "optional type hinting" is probably the most reassuring term that
> could be used, while still remaining accurate.
>

I like that.


>  > Instead of either 'nominal' or 'structural', use our own 'dynamical'
> > subclassing scheme.
> >
> > In other words:
> >
> >   def spamify(current: datetime.date, moved:int) -> bool:
> >      # ONE_DAY is a one day time delta, previously declared
> >      days = ONE_DAY * moved
> >      proposed_date = current + days
> >      return it_works(proposed_date)
> >
> > The type checker will not look to see if 'current' is a datetime.date,
> but
> > rather will check that what datetime.date's __add__ works with
> > (datetime.delta) and then check that what is passed in for current has an
> > __add__ that also works with datetime.delta.
> >
> > I think this would be far more valuable than just nominal as it follows
> > duck-typing, and hopefully less work than structural as it's only
> checking
> > the methods and attributes actually used.
>
> ABCs already support ducktyping, and explicit registration, etc, etc.
> We don't need a completely new type system, we can just file the rough
> edges off the categories we have already defined, and fill in some of
> the missing pieces (like allowing union types, which I seem to recall
> being discussed back in the PEP 3119 time frame, but postponed until
> more concrete use cases presented themselves).
>

Yeah, my response to Ethan's use case is that either he shouldn't bother
with type annotations, or he should probably care enough to also declare
his duck type for datetime.date as such, and an ABC regsitration sounds
perfect for that.


> We may even need to finally add String and BytesLike ABCs, but we've
> been muttering about doing that for years.
>

Mypy has some ideas here.

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