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

[Guido van Rossum]

On Sat, Jan 17, 2015 at 1:43 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Guido van Rossum schrieb am 16.01.2015 um 21:08:
> > I don't know what to answer for Cython -- doesn't it have its own syntax
> > for declaring C types? Or is it now also using annotations?
>
> It can, but it's optional. When I added support for it, I took care not to
> enable it by default, so that it wouldn't accidentally interfere with other
> usages of annotations.
>
> The current proposal seems less generous in this regard, and the way I see
> it, the only gain from Cython's point of view is its very limited support
> for container item type declarations and function signatures of callable
> objects. Both are restricted to Python object types and even imply slightly
> different semantics than Cython (I didn't see a notion of "exact types" as
> opposed to "type or subtype").
>

Actually, while the PEP is still lacking in clarity and we're still having
some discussions, type variables will most likely be "invariant" by
default, which I think is the "exact types" notion you are after. There's
lots of discussion in https://github.com/ambv/typehinting/issues/2 (you
might want to read this from the end :-).


> If there was at least a notion of "unknown types" that tools like static
> type checkers MUST ignore (couldn't find that in the PEP either), then
> Cython users could mix this with Cython's Python level type mapping through
> the "cython" magic module, e.g. something like "cython.struct(x=cython.int
> ,
> y=cython.p_char)".
>

Perhaps you could supply a stub for the cython module that declares
everything in it as type 'Any'? That should shut the type checker up.


> OTOH, Cython could easily understand the proposed type declarations and
> apply runtime type checks for them to compiled Python code. Not sure if
> that would be considered an interesting feature, though.
>

You should ask Cython's users what they think.

For me personally, it has taken me a long time to make peace with the idea
that the static type checker runs as a separate program, like a linter, and
has no effect on the runtime behavior of the program. But now that I have
made that peace, I feel it's easier to make progress. I no longer feel the
pressure to design a type system that can describe everything Python can do
(which is impossible). It's enough to design a type system that can
describe most of what most programmers do with Python most of the time
(when they're not feeling too hacky). As long as there's an escape to say
"don't worry about this part," such a type checker can be a very useful
tool (like a linter, but much better; it can also be used in an IDE).

(And in fact there are several escape hatches. You could choose not to run
the checker at all, or you could ignore some or all of its advice. Or you
can leave out annotations from parts of your program. Or you can use an
explicit 'Any' annotation. ('Any' is not the same as 'object'!) Or you can
use a decorator or a magic comment to disable checking of code that uses
annotations for other purposes.)

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