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

[Antoine Pitrou]

Le 21/04/2015 15:50, Paul Sokolovsky a écrit :
> Hello,
> 
> On Tue, 21 Apr 2015 15:08:27 +0200
> Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> []
> 
>> Because the user might not run the type checker, obviously. To quote
>> you: """When we say that type checking is optional, we mean it."""
>>
>> You can't at the same time point out that type checking has no
>> power or control over runtime behaviour, and then claim that type
>> checking makes runtime behaviour (for example, ability to accept or
>> reject certain types) saner. It is a trivial contradiction.
> 
> I suspected there's either short-sightedness, or just a word play for
> for a purpose of word play.
> 
> Type annotation are NOT introduced for the purpose of static type
> checking.

I was replying to Steven's message. Did you read it?

> Runtime type checking (run as via "make test", not
> as "production") is much more interesting to catch errors.

Obviously you're giving the word "runtime" a different meaning than I
do.  The type checker isn't supposed to actually execute the user's
functions (it's not that it's forbidden, simply that it's not how it
will work in all likelihood): therefore, it doesn't have any handle on
what *actually* happens at runtime, vs. what is declared in the typing
declarations.

But if by "runtime" you mean any action that happens *out-of-band*
during development (such as running pip or a syntax-checking linter),
then sure, fine :-)

> Even more interesting usage is to allow ahead-of-time, and thus
> unbloated, optimization. There're bunch of JITters and AOTters for
> Python language, each of which uses own syntax (via decorators, etc.)
> to annotate functions.

As a developer of one of those tools, I've already said that I find it
unlikely for the PEP to be useful for that purpose. The issue is that
the vocabulary created in the PEP is not extensible enough.

Note I'm not saying it's impossible. I'm just skeptical that in its
current form it will help us. And apparently none of our "competitors"
seems very enthusiastic either (feel free to prove me wrong: I might
have missed something :-)).

> Having language-specified type annotations
> allows for portable syntax for such optimized code.

Only if the annotations allow expressing the subtleties required by the
specific optimizer. For example, "Float" is too vague for Numba: we
would like to know if that is meant to be a single- or double-precision
float.

> Don't block the language if you're stuck
> with an unimaginative implementation, there's much more to Python than
> that.

The Python language doesn't really have anything to do with that. It's
just an additional library with a set of conventions. Which is also why
a PEP wouldn't be required to make it alive, it's just there to make it
an official standard.

Regards

Antoine.