[Python-ideas] Type Hinting Kick-off

[Guido van Rossum]

On Fri, Dec 26, 2014 at 12:00 PM, Eugene Toder <eltoder at gmail.com> wrote:

> On Thu, Dec 25, 2014 at 10:41 PM, Guido van Rossum <guido at python.org>
> wrote:
> [...]
> > Eek. That sounds like a bad idea -- copy.copy() uses introspection and I
> > don't think there's much hope to be able to spell its type.
> Does it really use more introspection than your space_for() function?
> Naively,
> copy is implemented like:
>
> def copy(obj):
>     if isinstance(obj, int): return obj
>     if isinstance(obj, list): return list(obj)
>     ...
>     return obj.__copy__()
>
> This does not seem very hard to type.


Well, it copies most class instances by just copying the __dict__. And it
recognizes a bunch of other protocols (__copy__ and most pickling
interfaces).


> There are much simpler examples, though:
>
> a) Keys of Dict and elements of Set must be Hashable,
> b) To use list.index() list elements must be Comparable,
> c) Arguments to min() and max() must be Ordered,
> d) Arguments to sum() must be Addable.
>
> So it's not uncommon to have generic functions that need restrictions on
> type
> variables.
>

I think you are still trying to design a type system that can express all
constraints exactly. In practice I doubt if any of the examples you mention
here will help catch many bugs in actual Python code; a type checker that
is blissfully unaware of these requirements will still be tremendously
useful. (I guess this is the point of gradual typing.)


> > That sounds like an artificial requirement on the implementation
> designed to
> > help the type checker.
> Perhaps I'm not explaining this right. The requirement is not for the type
> checker, it is to be able to implement the function. As you pointed out
> earlier, without any requirements on the type the function will not be
> able to
> produce the value.
>

Yeah, but my counter is that Python users today don't write classes like
that, and I don't want them to have to change their habits.


> > Peter Norvig mentioned that the subtleties of co/contra-variance of
> generic
> > types in Java were too complex for his daughter, and also reminded me
> that
> > Josh Bloch has said somewhere that he believed they made it too complex.
> IIUC the context for both statements is specifically the call site
> annotations
> of variance, i.e. <?T extends C> and <?T super C>. Though you can also
> quote
> Gilad Bracha, who declared that variance is too complicated notion for
> programmers to understand, and made all generics in Dart covariant. This
> was also the case in Beta, whose authors denounced invariance and
> contravariance, as coming from people "with type-checking background" :-)
>

I'm not sure I understand why you think that is funny. I think they all
have a point.


> > But I can see a serious downside as well. There will likely be multiple
> > tools that have to be able to read the type hinting annotations, e.g.
> IDEs
> > may want to use the type hints (possibly from stub files) for code
> > completion purposes. Also someone might want to write a decorator that
> > extracts the annotations and asserts that arguments match at run time.
> The
> > more handy shorthands we invent, the more complex all such tools will
> have
> > to be.
> I think if these tools cannot use functions from the typing module they
> will
> have bigger problems than shorthands. And the number of shorthands is
> pretty
> limited -- there are only as many literals in Python.
>

I think there are at least three separate use cases (note that none are
part of the proposal -- the proposal just enables a single notation to be
used for all three):

(1) Full type checkers like mypy. These have to parse everything without
ever running it, so they cannot use the typing module's primitives. They
may also have to parse stuff in comments (there are several places where
mypy needs a little help and the best place to put it is often in a #type:
comment), which rules out Python's ast module.

(2) Things that use runtime introspection, e.g. decorators that try to
enforce run time correctness. These can use the typing module's primitives.
I wish we could just always have (generic) type objects in the annotations,
so they could just look up the annotation and then use isinstance(), but I
fear that forward refs will spoil that simplicity anyway.

(3) IDEs. These typically need to be able to parse code that contains
errors. So they end up having their own, more forgiving parser.

That's enough distinct cases to make me want to compromise towards a
slightly more verbose syntax that requires less special handling. (I am
also compromising because I don't want to change CPython's parser and I
want to be able to backport typing.py to Python 3.4 and perhaps even 3.3.)

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