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 ? >>>> >>>> >>>>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 > play?
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 - really ? > and > 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 models... > 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 function. 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. cf above. > 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 > production.) > > Diez -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list