On Aug 28, 5:13 am, Mike Orr <[email protected]> wrote: > On Fri, Aug 27, 2010 at 12:51 AM, waugust <[email protected]> wrote: > > Greetings, > > > Hoping someone will be able to shed some light here. > > I'm building an application that requires to have something akin to > > stored procedure calls on controller actions. Its to customize a > > chain of actions in a sequence under determined variables....or > > something like that (its late). > > At any rate, my thought was to pickle a call to a controler with > > app.get(url('path')) though I'm getting "Can't pickle <type > > 'function'>: attribute lookup __builtin__.function failed" > > What exactly are you pickling? Pylons, Paste, and literal() use > various lambdas and inner functions in their execution path. These are > unpicklable because Python stores the function by name, and it must be > defined at the top level of its module, not a dynamic function. Even > if you're not pickling a function directly, it's possible that it's > ultimately defined as a function somehow. We'd need to know the exact > thing you're pickling in order to confirm that. > > > So I saw this:http://code.google.com/p/modwsgi/wiki/IssuesWithPickleModule > > > So, that's no a viable means to my end, I suppose? > > Maybe, but it would be somewhat complex to trace it. If you're running > the server with "--reload", that may be the "Script reloading" case. > Butmod_wsgiis a unique environment, so I'm not sure the precise > conditions apply outside it. Unless this is happening undermod_wsgi?
Not sure why they are referencing that page on mod_wsgi wiki, but what is described there is totally irrelevant to Pylons applications even if running under mod_wsgi. The issues there are only relevant to stuff defined in the WSGI script file itself and since for Pylons, and pretty well all other Python web frameworks, the WSGI script file is merely a place to adapt to the specific applications/frameworks method of interfacing with a WSGI server, you would never have any application code defined in the WSGI script file which would be getting pickled by your application. The reason it is an issue for stuff in WSGI script file is because the name given to the WSGI script file when loaded in memory isn't the same as base name of file in disk and nor is the directory the file is in in sys.path, so even if module name matched file, still couldn't be found. Graham > > Basically what I wanted to do is have a "Action" model with a action > > attribute to store a call to a controllers action in order to execute > > on demand during a procedure later (and in steps), if that makes more > > sense? > > > I guess I can't pickle controller actions? > > Is there a better pattern > > for something like this? > > Mmm, yes, it kind of makes sense, but I'm not sure how to structure > it. There are two basic ways to freeze a function call so that it can > be called later. One is to store the name of the function and each > argument separately, and then look up the function by name and call it > with the args. The other way is to store the function-call string and > eval() it later. Eval() is generally undersirable because (1) it may > not be able to evaluate it if the runtime environment has changed; > e.g., if imports it depends on haven't been made, and (2) accidents or > malicious users could fashion the string to execute code you handn't > intended, and (3) Python can't optimize the local variables in any > function that contains eval(). But sometimes eval() is necessary, and > this may be a case. > > Ultimately, what you'd want to save is the entire 'environ', because > any part of it may be relevant to the action or middleware. Are you > saving a real user request, or an artificial action call? An > artificial call is easier to recreate because you know which 'environ' > factors are relevant. For a real call, can't you just store the URL, > HTTP method, and request body? Then you could replay it at your > convenience. > > Sorry if this is a bit vague, but the problem is a bit vague to me. > > -- > Mike Orr <[email protected]> -- 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.
