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@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
