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

[Guido van Rossum]

I need to cut this subthread short, but basically, for a successful type
check, the expressions used in annotations *cannot* be arbitrary
expressions. The type checker has a special understanding of things defined
int 'typing', and it knows e.g. what typing.Union means. It supports simple
aliases through assignments, so that you can say e.g.

import typing
U = typing.Union
def foo(U[int, str]) -> str: ...

but it does not understand arbitrary call chaines, so that e.g. this does
*not* work:

import typing
def u(a, b): return typing.Union[a, b]
def foo(u(int, str)) -> str: ...

On Wed, Jan 21, 2015 at 10:27 AM, Matt <boehm.matthew at gmail.com> wrote:

> I think that since type hints have to be analyzed at compile time,
>> that execution of arbitrary Python code is a non-starter.
>
>
> From the way the abstract is worded, it sounds like arbitrary expressions
> could be used:
>
>
>> Abstract base classes, types available in the ``types`` module, and
>> user-defined classes may be used as type hints as well.  Annotations
>> must be valid expressions that evaluate without raising exceptions at
>> the time the function is defined
>
>
> I had assumed that this means that the annotation is any arbitrary python
> expression that evaluates to one of these things. Even if the syntax is
> more limited (as I guess it must be), I assume that Union and generics work
> not because the static analyzers know anything special about Union, but
> that typing.Union is a python class and could have just as easily been
> defined outside of the standard library. Even if function calls do not
> work, I imagine people can somehow abuse generics to capture documentation
> or other things inside type hints.
>
> As an example, let's say a function expects a positive integer. A
> programmer could achieve this with an assert statement near the top of the
> function, a decorator, or by making users pass in a PositiveInt object
> (subclass of int). However, they may prefer to annotate the function as
> Type[int, Positive]. Perhaps a better example would be something like
> Type[FilePath, exists, readable]
>
> I like the idea of keeping annotation syntax very simple and primarily
> about static type checking, but if it's true that people can experiment
> with other uses for function annotations without violating the current
> syntax, then it sounds like everybody wins.
>
>
> On Wed, Jan 21, 2015 at 11:45 AM, Skip Montanaro <skip.montanaro at gmail.com
> > wrote:
>
>> On Wed, Jan 21, 2015 at 10:38 AM, Matt <boehm.matthew at gmail.com> wrote:
>> > What do people think about allowing the annotation to be a function that
>> > returns the type? Is this too complicated to understand/implement?
>>
>> I think that since type hints have to be analyzed at compile time,
>> that execution of arbitrary Python code is a non-starter. Smarter
>> folks than me may well see a way this could happen though.
>>
>> Skip
>>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



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