[OT] code is data
bruno at modulix
onurb at xiludom.gro
Tue Jun 20 13:08:28 CEST 2006
Diez B. Roggisch wrote:
> bruno at modulix wrote:
>>Diez B. Roggisch wrote:
>>>>>because lots of people know how to describe XML transformations, and
>>>>>there are plenty of tools that implement such transformations
>>>>Efficiently enough for dynamic (runtime) use ?
>>>Using XML-transformation for AST manipulation isn't my first choice
>>>either - yet efficiency concerns aren't really the point here - after
>>>all we're talking about generating code,
>>I thought we were talking about *transforming* code - just like one uses
>>metaclasses to transform a class definition, or @decorators to transform
>>a function definition...
> Yes we were. So where does the runtime efficiency you mention come in to
class transformations via metaclasses and function wrapping does happen
at runtime - when the class or (decorated) def statements are eval'd.
This is not the same as having a distinct preprocessing phase that would
write a new .py file.
> While the _result_ of a transformation might be a less efficient piece of
> code (e.g. introducing a lock around each call to enable concurrent
> access), the transformation itself is very - if not totally - static -
> usually only run once.
Nope, it's runned each time the module is loaded (with 'loaded' distinct
from 'imported') - which can make a real difference in some execution
> So except from a start up latency, it has no impact.
Having a high startup latency can be a problem in itself.
But the problem may not be restricted to startup latency. If for example
you use a metaclasse and a function that *dynamically* creates new
classes using this metaclass, then both the class statement and the
metaclass code transformation will be executed on each call to this
The whole point of a code transformation mechanism like the one Anton is
talking about is to be dynamic. Else one just needs a preprocessor...
> So if for whatever
> reason XSLT is someones favorite method of AST-transformation because it
> fits her mindset - perfect. As I said: it wouldn't be mine either, but I
> can't see your concerns about efficiency.
> And XSLT certainly is suited for tree manipulation, so it might be that it
> would be good for e.g. recursivly stripping type annotations of some kind
> (think of e.g. type-verifying decorators that you want to get rid of for
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"
More information about the Python-list