[Python-ideas] PEP 484 (Type Hints) -- first draft round

Guido van Rossum guido at python.org
Fri Jan 16 22:51:31 CET 2015


On Fri, Jan 16, 2015 at 1:39 PM, Dennis Brakhane <brakhane at googlemail.com>
wrote:

> >
> >     Forward references <https://www.python.org/dev/peps/pep-0484/#id9>
> >
> > When a type hint contains names that have not been defined yet, that
> > definition may be expressed as a string, to be resolved later.
>
> Is it intentionally undefined when exactly "later" is?
>

I doubt it is. But specifying the exact semantics of every nit of the
static type checking algorithm is beyond the scope of the PEP -- it would
be as complex as the implementation of mypy. The intention is that this is
a forward reference to something defined at some later point in the same
file.


> Silly example:
>
> from typing import Set
>
> def foo(bar: 'Set[Employee]') -> None:
>     ...
>
> class Employee:
>     ...
>
> def foo2(bar: Set[Employee]) -> None:
>     ...
>
> class Set(Generic[T]): # oops, I didn't pay attention and redefined Set
>     ...
>

I think a static checker should always warn about such redefinitions.


>
>
> A conforming type checker could interpret the type of foo in two ways so
> that foo either takes a normal set (resolved right after Employee was
> defined) or an instance of the new class Set (what Set refers to at the
> end of the file).
>
> In the first case, the signatures of foo and foo2 are the same, in the
> second one, foo2(bar: Set[Employee]) and foo2(bar: 'Set[Employee]') mean
> different things.
>
> Of course, a good style checker should have slapped the user for
> redefining Set, so it's more of a academic problem and leaving "later"
> vague doesn't matter in practise, but I'd still document the fact that
> conforming implementations are free to choose what later means.
>
>
>
Right. This doesn't really bother me much.

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


More information about the Python-ideas mailing list