Ah, I see your point, a python compiler for my python code. Interesting strategy!
Thanks for taking the time to outline your idea, I can see what you mean about the article now. It's funny, because on the surface, it seemed to me that taking existing python scripts and making them work through a webpage via pylons would be a trivial/easy task. I can see now that is not necessarily the case, at least for a console-based application like I'm dealing with. Thanks again for all the inputs! On Jul 3, 3:28 pm, "Jon Rosebaugh" <[EMAIL PROTECTED]> wrote: > On 7/3/07, Brian <[EMAIL PROTECTED]> wrote: > > > > > On Jul 2, 5:43 pm, "Jon Rosebaugh" <[EMAIL PROTECTED]> wrote: > > > On 7/2/07, Brian <[EMAIL PROTECTED]> wrote: > > > > I should note that this library of existing scripts is quite large, > > > > and attempting to modify them (ie change prints to something else) > > > > would be a bit of work. I DID attempt to go the route of making a > > > > controller return a generator that invokes my initial function, > > > > however this quickly turned into a mess since generators may not > > > > 'return' values, and many of the classes used in these scripts > > > > regularly return values and results of function calls. > > > > Steve Yegge talked about this problem (in the generic case, not > > > specific to Pylons or Python) in one of his recent blog posts. I think > > > you may find it to be fascinating > > > reading:http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html > > > I've actually read that article before, but not sure how it relates to > > my problem. Unless of course you're just saying that I'm not a good > > pylons/python programmer, which I'd readily admit (thus my comment > > about being new to the arena). > > I'm suggesting that your problem could be solved through the use of > what would technically be called a 'compiler'. Situation 3 and > Situation 7 described in that blog post are very similar to your > problem. Half of the work is already done for you, in that Python > ships with several modules that will handle the parsing phase quite > nicely. For example: > > >>> compiler.parse("result = a + 5") > > Module(None, Stmt([Assign([AssName('result', 'OP_ASSIGN')], > Add((Name('a'), Const(5))))]))>>> compiler.parse("print signal_value") > > Module(None, Stmt([Printnl([Name('signal_value')], None)])) > > Once you've done that, you need to figure out what you want to replace > those print statements _with_. Maybe you could call a function, and > the function imports pylons.request and gets the current environ, and > finds an 'output buffer' in the environ somewhere, and appends the > string to that. > > Then you just need to convert the AST back into code. Quite a bit of > work has already been done in this area, particularly with relation to > Python 3000. > Seehttp://jeremyhylton.blogspot.com/2006/08/python-3000-translation-stra... > for an example of one blog post talking about it. > > Of course, if you're content with doing this transformation every time > you load these scripts -- maybe this isn't a performance-critical app > -- you can just run the modified AST as-is. > > The end result would be a 'compiler' that compiles your print-using > Python code to non-print-using Python code. It's best really to think > of a compiler as just "any program that converts code from one form to > another' when you're thinking about problem solving, which was the > point of Steve's essay. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
