[pypy-dev] rpython and pep 484

[Armin Rigo]

Hi,

On 25 January 2015 at 00:05, Ho33e5 <ho33e5 at gmail.com> wrote:
> What is your view on the new typing/mypy things that are happening on python-dev
> (pep 484)? What I mean is will this make the typing system of rpython evolve? Could
> RTyper be adapted to work on pep 484 annotations (would it actually be useful)?

You are confusing RPython for being "Python-with-type-annotations".
It is not: RPython does not have explicit types annotations.

I think that this alone invalidates the rest of your discussion about
RPython.  So let's instead talk about "APython", which would be
Python-with-type-annotations.  (If we're designing some new language,
it can be like Python 3.x for x large enough to include support for
the pep 484 syntax, as opposed to RPython which is a subset of Python
2.)

> An other question that is related: it's maybe early to think about that but could it be
> reasonable to expect that pypy will better optimize pep-484-annotated python programs?
> The thrusting of these user annotations is indeed a problem, so a pypy option could
> specify that we want it to thrust the type annotations.

The type annotations have not been written with low-level performance
in mind.  For example, there is no standard type annotation that means
"this is a machine-sized integer"; you have only "this is a Python 3
int object", which is a Python 2 "int-or-long".  Similarly, there is
no mention in PEP 484 about specifying the type of instance
attributes, for example.

So APython would need a subtly different set of types to work on.
Let's ignore the problem that this breaks compatibility with any other
tool written for PEP 484.  It is very unclear how much speed PyPy
could potentially gain.  Basically we would trade removing an unknown
but likely small fraction of the guards emitted by the JIT compiler
against the very real result of PyPy segfaulting as soon as there is a
mismatch somewhere.  At least in C++ the compiler does some real type
checking and reports to you.  Supporting the APython approach would
basically be a lot of hard work (for us) with the end result of giving
users a sure way to shoot themselves in the foot.

I would argue that there are plenty of old ways to shoot yourself in
the foot which are at least more supported by a large number of tools.
For example, C++ comes with two essential tools that would be missing:
the first is the C++ compiler itself, which does a better job at
reporting typing errors than any best-effort type checker can; the
second is gdb.  I would argue that you first need equivalents of these
two tools.

Exact type checking is stricter than best-effort.  I doubt that it is
possible to write such a tool that would accept large 3rd-party Python
libraries which have not been structured for type-checking in the
first place.  If you think otherwise, then I would say it is your job
to write it --- this would seem like a reasonable first step along
this path :-)


A bientôt,

Armin.