PyPy 1.0: JIT compilers for free and more

[Kay Schluehr]

On Mar 28, 2:54 pm, "Paul Boddie" <p... at boddie.org.uk> wrote:
> On 28 Mar, 14:12, "Kay Schluehr" <kay.schlu... at gmx.net> wrote:
>
>
>
> > A somewhat unrelated question. With Py3K Python gets optional type
> > annotations.
>
> No, I believe the consensus is that Python 3000 gets optional
> annotations which aren't specifically for type information... nudge
> nudge, wink wink! That last part is important, because that's also how
> many other people have interpreted this particular feature.

You are right. The feature is more situated on a syntactical /
interface level. The semantical level has to be specified by
annotation handlers. Among them there will also be those that deal
with type annotations. I have little doubts that one of them will make
it into the stdlib sooner or later and might also influence
compilation.

> I seem to
> recall that some of the PyPy people weren't interested in static
> analysis [1], so I'm skeptical about whether type annotations are
> their kind of thing, either.

That's why I asked the question with regard to Py3K style annotations
and not static analysis in Py2X which I consider intractible. The JIT
measures types at runtime and optimizes code using this information
but doing things in this style global optimizations are hardly
tractible as well. My main interest is in an intermediate level, given
type measurements as a byproduct of UTs and code coverage. This
methodology is process-oriented and non interferent.

> That said, I imagine that the handling of
> metadata (including type details) is an element in the way RPython
> works, but I also imagine that things get more complicated as such
> metadata diverges from plain type information and into arbitrary
> "observations" about other aspects of program behaviour.

RPython is heuristically defined as a subset of Python "static enough
to be translatable to C". So it is actually static analysis that is
done here, not on a local scale but on a simpler sublanguage. It is
not clear to me whether for a sufficiently annotated Py3K program the
inequation RPython != Python still holds?

> Still, I'd like to see the PyPy people stick their necks out and
> answer your questions. ;-)
>
> Paul
>
> [1]http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html