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? 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 - and usually only run once. So except from a start up latency, it has no impact. 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 production.) Diez -- http://mail.python.org/mailman/listinfo/python-list