[pypy-dev] PyPy for analysis?

[Ronan Lamy]

Le 07/09/14 12:42, Scott West a écrit :
> Hello all,
>
> I was looking recently into trying to do some simple static analysis of
> Python programs (to experiment with what is possible), and came across
> PyPy. Reading some of the documentation it seems that PyPy forms a
> control flow graph and does some abstract interpretation, which seems to
> indicate that it could be used for other forms of static analysis!

First, PyPy doesn't do static analysis, it's the RPython toolchain 
[http://rpython.readthedocs.org/en/improve-docs/getting-started.html] 
that does.

>
> I had a couple questions:
>    1) Would PyPy (seem) to be a good place to start for a general
> analysis framework? If so, would it be of general interest?

Yes and no. The RPython toolchain does a lot of complex analysis, 
however it's meant to be used on RPython programs, not arbitrary Python. 
This means that it'll error out on valid Python code more often than not.

>    2) If one doesn't care about code generation, can the build time be
> reduced? I tried just using pyinteractive.py and that _seemed_ to work,
> though even that compiles a few things to start.

The annotation phase, where most of the analysis is done, takes only a 
fraction of the time of a full translation. You can run only that by 
calling 'rpython --translate' instead of 'rpython'. It checks that the 
program is RPython and generates all the type-inferred flow graphs but 
note that it doesn't yield any useful artefact.

pyinteractive.py simply runs PyPy as a Python program on top of your 
standard interpreter. It's not useful for static analysis.

For an interactive way of running the toolchain, use 
rpython.translator.interactive (you need to have pygame and graphviz 
installed). For instance:

 >>> from rpython.translator.interactive import Translation
 >>> def f(n): return n+1
 >>> t = Translation(f, [int])
 >>> t.annotate()
 >>> t.view()

>    3) What is a good way to get into modifying the internals (adding
> analyses, skipping code gen.)? I have read the chapter of the Open
> Source Architecture book, and some of the documentation pages.

The internals are poorly documented and have messy interdependencies. 
The AOSA chapter is somewhat outdated. OTOH the code is relatively well 
tested. So your best bet is to come ask questions on IRC (#pypy on 
freenode.net) and use test-driven development.
>
> I would be most grateful if anyone could provide any comments on these
> issues, or pointers to other similar works.
>
> Thanks!
>
> Regards,
> Scott
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev