[Python-3000] Refactoring tool available (work in progress)

Talin talin at acm.org
Fri Dec 15 07:56:49 CET 2006


Guido van Rossum wrote:
> In the sandbox I've been working on a refactoring tool, which could
> form the basis for a Python 2.x -> 3.0 conversion tool.  I'd like to
> invite folks here to give it a try and give me a hand. It certainly
> needs more work, but I think that the basic infrastructure is sound.
> Check out sandbox/2to3/:
> http://svn.python.org/view/sandbox/trunk/2to3/.
> 
> This message is to invite feedback, and to encourage contributions. It
> would be great if people tried their hands at writing new
> transformations!

And here I thought Py3K wasn't going to have programmable syntax :)

I was working on a related idea recently, involving syntactical 
transformations, although not directly related to Python. One of the 
things I discovered was that it was possible in many cases to use the 
same parser on both the transformation patterns and the text to be 
translated. This allowed the transformation patterns to look a lot like 
the source and target patterns, instead of having to have a special 
syntax for the transformations.

Ideally, you ought to be able to say something like:

    apply(?f, ?x, ?y) => f(*x, **y)

You'd have to add an exception to the parser to recognize the unbound 
variable prefix ('?') when parsing patterns.

You could also put constraints on the bound variables:

    apply(?(expr:f), ?x, ?y) => (f)(*x, **y)
    apply(?f, ?x, ?y) => f(*x, **y)

In other words, if we need parens (because 'f' is an expression), then 
match the first rule, otherwise the second. Although a better way to 
handle the case of the parens is by repeated transformation:

    apply(?f, ?x, ?y) => paren(f)(*x, **y)
    paren(?(var:f)) => f
    paren(?f) => (f)

In this case, we transform 'f' into 'paren(f)', and then transform that 
into either 'f' or '(f)' depending on whether it's a simple variable or 
an expression. This allows us to only have one version of the 'apply' rule.

(Although the specific case of parenthesis logic ought to be built in, 
as you have already done, since it's going to clutter up every rule 
otherwise. Mainly I wanted to use it as an example to show constraints.)

What I'm describing is exactly the same logic as an algebraic solver, 
which many people have written in Python already.

One other thing you might want to do is look at the parser generator 
ANTLR (www.antlr.org), which has a syntax for tree transformations and 
pattern matching of tree fragments.

Anyway - it looks pretty cool :)

-- Talin


More information about the Python-3000 mailing list