Use annotations for type hinting?

[Mart Sõmermaa]

The ProjectPlan wiki page lists type feedback as one of the
planned optimizations. Automatic typing via runtime
information gathering is on the roadmap, but it is costly
and complex -- so wouldn't it make sense to provide a
shortcut for explicit type hinting via annotations (PEP
3107)? That would probably be both an easy start and a good
testbed for typing support and will probably bring
considerable performance gain to annotated code for
relatively(*) little effort.

(Considering that func_annotations is mutable, it would be
even possible to support explicit runtime control over type
hinting -- whether supporting that is practical is another
matter.)

Best,
Mart Sõmermaa

(*) "Relatively" == "compared with implementing full-blown
automatic typing".

[Reid Kleckner]

That's an interesting route to take, but it doesn't help us speed up
existing idiomatic Python. We're not trying to change the Python
language or programming practices, just to speed it up.

What semantics do you think annotations should have? Does an
annotated method just check its argument types at call time and raise
a TypeError if it doesn't match? What if I have an argument annotated
to be of type Foo, and I want to inline the method Foo.bar. What if
someone passes me an instance of Foo with a bar attribute, thereby
overriding the class method? One would need to be able to express in
the type annotation not just the class, but also the "shape" of the
object. IMO to deal with this problem we need to use maps/hidden
classes ala V8 and Self.

I'd like to see someone do something creative with those annotations,
but we're not planning on using annotations because that would be too
disruptive on the language front.

Doing good type feedback may be hard, but I think it'll be much more
worthwhile in the long run.

Reid

[mrts]

On Nov 9, 1:32 am, Reid Kleckner <r...@mit.edu> wrote:
> That's an interesting route to take, but it doesn't help us speed up
> existing idiomatic Python.  We're not trying to change the Python
> language or programming practices, just to speed it up.

Roger. Adding type hinting via annotations just looks like a
relatively easy shortcut on the long and winding path to automatic
typing:

1. Backport annotations from py3k.
More or less straightforward code conversion, not much
thinking involved.

2. Decide on a canonical type labeling syntax.
Can be intentionally simple and limiting --
the goal is not completeness but getting started
with typing as soon as possible.

3. Implement the actual type feedback-based
optimizations (TFO).
Needs to be done anyway and will be re-used
as-is in the final automatic implementation.

4. Bridge annotations and TFO.
Extract labels from func_annotations and if they happen
to be in the known types map, generate typed versions
of the function objects when translating the bytecode to
LLVM IR (or in some other stage in the code generation
chain, i.e. as planned in the automatic TFO framework).

> What semantics do you think annotations should have?  Does an
> annotated method just check its argument types at call time and raise
> a TypeError if it doesn't match?

Nope. It behaves exactly like the planned automatic TFO framework,
presumably just falling back to the unoptimized path if taking
the optimized one fails. IMHO, the labels should be just type hints,
not a half-baked strict typing system.

> What if I have an argument annotated
> to be of type Foo, and I want to inline the method Foo.bar.  What if
> someone passes me an instance of Foo with a bar attribute, thereby
> overriding the class method?  One would need to be able to express in
> the type annotation not just the class, but also the "shape" of the
> object.  IMO to deal with this problem we need to use maps/hidden
> classes ala V8 and Self.

What is the plan for handling these cases under the automatic TFO
framework? Why not just follow those plans?

> I'd like to see someone do something creative with those annotations,
> but we're not planning on using annotations because that would be too
> disruptive on the language front.
>
> Doing good type feedback may be hard, but I think it'll be much more
> worthwhile in the long run.

Agreed. Type hinting is not a substitute, but an immediately useful
initial step in that direction. Apart from being useful for annotated
code, the implementation would also help to gauge the potential
perfomance benefits of TFO.

[Collin Winter]

Hi Mart,

On Mon, Nov 9, 2009 at 1:17 PM, mrts <mrts....@gmail.com> wrote:
> On Nov 9, 1:32 am, Reid Kleckner <r...@mit.edu> wrote:
>> That's an interesting route to take, but it doesn't help us speed up
>> existing idiomatic Python.  We're not trying to change the Python
>> language or programming practices, just to speed it up.
>
> Roger. Adding type hinting via annotations just looks like a
> relatively easy shortcut on the long and winding path to automatic
> typing:
>
> 1. Backport annotations from py3k.
>   More or less straightforward code conversion, not much
>   thinking involved.

We've restricted ourselves to staying compatible with Python 2.6. We
cannot unilaterally change the language's syntax or semantics, since
then we wouldn't be an implementation of Python 2.6 any longer.

> 2. Decide on a canonical type labeling syntax.
>   Can be intentionally simple and limiting --
>   the goal is not completeness but getting started
>   with typing as soon as possible.
>
> 3. Implement the actual type feedback-based
>   optimizations (TFO).
>   Needs to be done anyway and will be re-used
>   as-is in the final automatic implementation.
>
> 4. Bridge annotations and TFO.
>   Extract labels from func_annotations and if they happen
>   to be in the known types map, generate typed versions
>   of the function objects when translating the bytecode to
>   LLVM IR (or in some other stage in the code generation
>   chain, i.e. as planned in the automatic TFO framework).
>

[snip]

>
> Agreed. Type hinting is not a substitute, but an immediately useful
> initial step in that direction. Apart from being useful for annotated
> code, the implementation would also help to gauge the potential
> perfomance benefits of TFO.

Getting the data -- type feedback vs type annotations -- isn't the
hard part; the hard part is actually implementing the optimizations.
We've been working the past two quarters to get the LLVM-side
infrastructure in place to make these optimizations easier to
implement and maintain, and now that we have that work in place, we
can start on the fun stuff. We've been pursuing a path of inlining the
calls into Python C runtime top-down (go all the way down the call
chain), then take advantage of LLVM's optimizers to eliminate all the
code we don't need.

If that's something you're interested in, we're certainly looking for
other contributors :)

Thanks,
Collin Winter