Olivier Favre-Simon wrote:
Hi Cliff,
Not a real breakage, rather an issue with eval() itself.
I hacked a quick and dirty prototype based on Buffet-0.4 and TurboStan-0.7.
eval() was crying on the CRs in the template file but:
Actually I've seen the same thing and never had an explanation for it.
I found myself having to run unix2dos on a file with fragments
copy/pasted from the web (getting a "syntax error" on blank lines, for
instance). I don't think this should happen, although the idea of an
actual bug in Python is a bit startling to me. AFAIK, Python is
supposed to handle newline translation transparently and I'm not aware
that eval() is an exception to that (although it seems possible that the
type of translation happening is global, at least within the scope of
the current module and that fragments of code within that module must be
of the same line-ending type... but that's just speculation).
One thing I will note about your adapters.py is that "from foo import
*" doesn't work in the context of a function definition. That is why,
along with the avoidance of namespace pollution, I use __import__ in
TurboStan for getting nevow.tags into the template namespace:
Python 2.4.2 (#1, Oct 16 2005, 16:00:21)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
... from stan.tags import *
...
<stdin>:1: SyntaxWarning: import * only allowed at module level
>>> def foo():
... ns = {}
... __import__('stan.tags', '__all__', ns, ns)
...
>>>
This effectively creates a namespace that the Stan template can be
eval()'d in that provides easy access to all the Stan predefined tags
and doesn't stick things like "a" and "p" into the outer module's
namespace where they might cause... confusion ;-)
Regards,
Cliff
