[Python-Dev] Type hints -- a mediocre programmer's reaction

Cory Benfield cory at lukasa.co.uk
Tue Apr 21 11:33:28 CEST 2015


On 21 April 2015 at 10:10, Chris Angelico <rosuav at gmail.com> wrote:
> At this point, you may want to just stop caring about the exact type.
> Part of the point of gradual typing is that you can short-cut a lot of
> this. And quite frankly, this isn't really helping anything. Just skip
> it and say that it's Union[Mapping, Iterable, None].

I think this is my problem with the proposal. This change doesn't
catch any of the bugs anyone was going to hit (no-one is passing a
callable to this parameter), and it doesn't catch any of the bugs
someone might actually hit (getting the tuple elements in the wrong
order, for example). At this point the type signature is worse than
useless.

It seems like the only place the type annotations will get used is in
relatively trivial cases where the types are obvious anyway. I don't
deny that *some* bugs will be caught, but I suspect they'll
overwhelmingly be crass ones that would have been caught quickly
anyway. The minute a type signature might actually help prevent a
subtle bug we can't use them anymore because the toolchain isn't
powerful enough to do it so we just put 'Any' and call it a day. And
even then we haven't helped the trivial case much because anyone who
wants to provide a duck-typed object that should be perfectly suitable
in this case no longer can.

What this proposal *needs* to be generally useful, IMO, is the ability
to specify types that actually match the way we have encouraged people
to write code: duck typed, favouring composition over inheritance,
etc. At the very least that means 'type constraints' (see Haskell,
Rust, really any language with a powerful and robust type system:
hell, even see Go's interfaces) need to be something we can specify.


More information about the Python-Dev mailing list