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

[Paul Sokolovsky]

Hello,

On Tue, 21 Apr 2015 16:11:51 +0200
Antoine Pitrou <antoine at python.org> wrote:

[]
> >> 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?

Yes. And I try to follow general course of discussion, as its hard to
follow individual sub-threads. And for example yesterday's big theme
was people blackmailing that they stop contributing to stdlib if
annotations are in, and today's theme appear to be people telling that
static type checking won't be useful. And just your reply to Steven
was a final straw which prompted me to point out that static type
checking is not a crux of it, but just one (not the biggest IMHO) usage.

> > 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.

Well, maybe "typechecker" is the wrong word then. I'm talking about
instrumented VM which actually interprets type annotation while running
bytecode - for example, on entry to a function, it takes argument
annotations, and executes sequence of equivalent isinstance() checks,
etc., etc. One won't use such instrumented VM at "production" runtime,
but it will be useful to enable while running testsuite (or integration
tests), to catch more issues.

> > 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.

How so, if it essentially allows you make typedefs? Syntax of such
typedef follow basic conventions (so *any* tool should understand
its *basic* semantics), but you're free to assign (implicit, particular
for your tool, but of course documented for it) semantics.

> 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"

That's my biggest fear - that "JIT" Python community is not yet ready to
receive and value this feature. 

> seems very enthusiastic either (feel free to prove me wrong: I might
> have missed something :-)).

Let me try: MicroPython already uses type annotations for statically
typed functions. E.g.

def add(x:int, y:int):
    return x + y

will translate the function to just 2 machine instructions. And we'd
prefer to use standard language syntax, instead of having our own
conventions (e.g. above you see that return type "is inferred").

> > 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.

Oh really, you care to support single-precisions in Numba? We have a lot
of problems with sfloats in MicroPython, because whole Python stdlib API
was written with implicit assumption that float is (at least) double.
E.g., we cannot have time.time() which both returns fractional seconds
and is based of Jan 1, 1970 - there's simply not enough bits in
single-precision floats! It's on my backlog to bring up this and
related issues before wider Python development community.

Anyway, back to your example, it would be done like:

SFloat = float
DFloat = float

For a random tool out there, "SFloat" and "DFloat" would be just
aliases to floats, but Numba will know they have additional semantics
behind them. (That assumes that typedefs like SFloat can be accessed in
symbolic form - that's certainly possible if you have your own
parser/VM, but might worth to think how to do it on "CPython" level).

> > 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.

Yes, and IMHO "JIT/compiler" Python community is too fragmented and to
unaware (ignorant?) of other projects' efforts, and having "official
standard" would help both "JIT" community and to establish Python as a
language with support for efficient compile-time optimizations.

> 
> Regards
> 
> Antoine.


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com