RPython, static type annotations, SafePython project (was: PhD Python & Smalltalk grant possibility (Lille/INRIA))

[Stefan Behnel]

Mariano Reingart, 05.09.2012 18:53, on python-announce-list:
> Context: Dynamically-typed languages cannot take advantage of static
> type information. In this context we would like to study
> the benefit of the introduction of static types *annotations* on
> library design and general robustness.

Works to a certain extent, but won't get you very far. You'll notice that
static types don't have all that rich semantics, so you'll eventually end
up wanting to extend the type declarations into contract specifications,
and then you'll end up duplicating half of your code to describe the
interface at some point. Has been done, IMHO not worth doing.


> The benefits can be at the level of the robustness (bug
> identification), but also tools (IDE) and support for assembly
> generation/c in case of JIT.

As the PyPy people keep reiterating, JITs (read: their JIT) don't need
static type declarations.

IDEs can benefit from them a bit (not much, just a bit - guessing usually
works quite well here), but I'd hate to change my code only to make my IDE
happy.

Static compilers obviously benefit from them, so you should take a look at
Cython if you are interested in a Python based type system with optional
static type declarations and how people use them in real code. (There's
definitely a lot more Cython code out there than RPython code...)


> The PhD grant is financed in the context of the Safe Python project
> therefore the Ph.D. will have to work in contact
> do we with the project partners and help in the context of some deliverables.
> 
> The following tasks have to be done:
> 
>         - RPython is not formally defined. One of the first task will
> be to define the formal semantic of RPython.

Just to be sure: you are talking about RPython, the language that PyPy is
(mostly) written in, right? Why would you want to restrict yourself to that
instead of looking at general Python code? Is that due to those who pay the
project or because it's really of interest all by itself?


>         One approach is to write a RPython interpreter based on an
> operational semantics and to compare the output
>         with the RPython interpreter. We will certainly use PLT redex
> which is a domain-specific language to specify
>         and debug operational semantics.

Sounds like a research-only project to me. From what I hear, RPython isn't
really an interesting programming language. It's very restrictive and easy
to get wrong. That might be related to the fact that the only definition of
the language is the only existing (incomplete) implementation, but maybe
not. (Sounds like some research could help to decide that at least).

There's also ShedSkin, which, I believe, has its own definition of an
"RPython", again based on what it understands and can statically analyse.


>         - We may use the abstract syntax tree of PyLint and use the
> Frama-C infrastructure. We will also consider to
>         build a Python parser based on petitParser.

My advice: skip the parser part, use the existing AST that Python provides.
That's the only sane way to integrate with other tools that process Python
code.


>         - Define of some default metrics may also be necessary for the
> SafePython project. Their definition should
>         be trivial on ASTs.

Not sure what you mean with "default metrics" here.


>         - Analysis of the benefits of static typing for RPython. One
> idea is to study the existing python libraries
>         and analyze the "distance" to the RPython subset.

That might be an interesting study in its own right: how static is
real-world Python code?


>         - Exploring type checking in presence of inconsistent type annotations.

Yep, that's only one of the problems you'll run into.


>         - Since we are developing Pharo

Which, if I searched correcly, is a Smalltalk IDE?

> and that static type annotation are important to
>         support C or assembly generation, we would like to apply the
> same technique to Pharo:
>                 - define a syntax to support type annotation (reuse
> the one developed by Pleaid team member)
>                 - perform some analysis of existing library.

I don't know Smalltalk well enough to comment on this.


> About Lille and INRIA:
> 
> Lille is located in the north of france at the border to Belgium
> one hour from Paris, 1h20 from London, 35 min from Brussels, by train.

And the most important thing (which you forgot to mention): a nice place to
live.


> French food, combined with belgian beer.

Well, yes, but it's still a nice place to live.

Stefan