2008/12/17 wmiller <[email protected]>: > >> > The templating is working as designed and it's pretty responsive >> > subjectively speaking. For those who might be interested, I'll post >> > some code and benchmarks after taking some time to clean up the code >> > and figure out a "safe" way to use eval within the template. >> >> You should avoid 'eval', at least in any context where the input could >> come from a remote user by way of URL, post data, query string etc >> etc. What are you trying to do that requires eval? >> >> Graham > > to process python code between the <% %> tags, e.g. > > <% > def fib(n): > a, b = 0, 1 > while b < n: > print(str(b) + ", ") > a, b = b, a+b > return b-a > > var = fib(100) > %> > <br><br> > {var} > > looks like this in a browser: > > """ > 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, > > 55 > """ > > here the the print statement is modified to just return output to the > browser. Also, variables surrounded by "{" "}" are returned to the > browser based on the variables in locals(). I'm still holding out > hope that there'll be a way to make eval safe or maybe figure out a > better alternative to allow scripting in the template.
You should perhaps look at how Python Server Pages (PSP) in mod_python is implemented. Documentation at: http://www.modpython.org/live/current/doc-html/pyapi-psp.html But look at mod_python source code. Your comments about 'print' show up one of the problems with a lot of these attempts to add Python into HTML. That is the expectation that 'print' output should appear in response stream. There are two approaches which people normally use for this. The first is to replace sys.stdout with some object which routes output back into response stream. The problem with replacing sys.stdout is ensuring it is safe in multithreaded environment. You can't just replace sys.stdout for life time of your request as in multithreaded context another request handler could do same thing and output could go to wrong response. You also have problems where third party module has used 'print' to produce debug output. Instead of going to a log file, that debug output will end up in response when not intended. The second approach is to compile template code and then replace 'print' opcode with alternate opcodes which direct output to a specific stream object corresponding to response. This is the better approach but requires more work and better done in conjunction with a page code caching scheme to avoid having to do it every time. A scheme which just tries to do textual substitution of 'print' in code before evaling/compiling it is not a good idea. Which of the above are you trying to use to ensure 'print' goes where you want? As to eval, ultimately somewhere the code has to be compiled and run and so you can't avoid evaluating it. The problem is just ensuring that text which comes from URL, headers or post content doesn't get expanded into code string before being evaluated. Where exactly are you using 'eval'? Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
