On Sun, Mar 14, 2010 at 8:38 AM, Hans Lellelid <h...@velum.net> wrote: > Hi pylons devs, > > First of all, I've been using Pylons for awhile now and want to thank > the developers for a great project. Typically, the way that we use > Pylons is for web services applications, not actually "web sites" -- > typically AMF or JSON-RPC (we have very little need for templates and > basically no use for forms, form validation, etc.). The fact that > Pylons is built on WSGI is priceless for this type of application and > make integrating new gateways, etc. so trivial. We love that about > Pylons. > > So, here's my question: is there any plan or interest in a Pylons > (Paste?) that does *not* use stacked object proxies for things like > request, session, etc?
SOPs have been controversial for a long time. You might find it interesting searching the pylons-discuss archives. I think there's an attribute on the controller instance, ``._py_object``, that contains the request/response/session, etc. And I think you can disable the magic globals by commenting out the RegistryManager in middleware.py. You can hunt about in the interactive traceback. > I think I understand the use-case for this, but have to say that it > really adds a lot of complexity -- particularly in the area of testing > -- and it seems to only enable a very specific (rare?) use case. If > there was only some sort of flag ... or a Pylons fork that just used > thread-local storage for these "globals". I never want to run > multiple applications in the same thread context; does anyone really > *need* to do that? It's a rare use case. There has been a lot of discussion about replacing the SOPs with threadlocals. Also, Pylons 2, built on Marco, will not depend on them, although the compatibility layer will have to support them for existing apps. > These stacked object proxies are just a royal pain > to debug. I imagine most developers just throw up a white flag when > they have a run in with one of these quizzical beasts. The main thing to remember is that ``sop._current_obj()`` returns the original object. Some builtin functions aren't proxied -- I don't remember if it's dir(), vars(), or dict() -- so you get back the SOP's attributes rather than the original object's attributes. In those cases you have to use ._current_obj(). Otherwise, what actual problems are you having with the SOPs? They work most of the time; that's why there hasn't been a major push to get rid of them. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
