Justin Tulloss wrote: > (....) > In addition, > it's very difficult to inspect the object that an SOP refers to since > it obfuscates the object's __dict__.
This trick can help: req = pylons.request._current_obj() # get current request object wrapped by SOP print dir(req) Again, it's just a matter of documentation IMHO. The alternative would be to make Pylons apps singletons like TurboGears 1, CherryPy 2, Django... are and that would solve the root of the "problem". A stacked proxy is only needed when the possibility exists of a WSGI app/middleware dispatching to another application that makes use of the same SOPs (a pylons app that calls another pylons app, or an app that uses "pseudo-middleware" [1] X that calls an app that also uses X). However, this alternative would be a *huge* step backwards IMO since it would make this pseudo-middleware less interoperable After all, from what I understand, one of Pylons design goals is to let you build your app from all this tiny wsgi pieces that play well together. Alberto [1] By pseudo WSGI middleware I mean middleware that is not really WSGI middleware since middleware should be transparent to the application it wraps, that is, if it's missing from the stack then the application could not care less about it. These are more like a fancy function decorator which usually sets setup some context for some library downstream that needs it, for example: toscawidgets, beaker, etc... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
