Re: Where does _py_object come from?

[Ben Bangert]

On Jan 15, 2009, at 3:55 AM, mk wrote:

However, if *elsewhere* I inherit from BaseController or from anything
that has _py_object attribute in the interactive debugger, this
_py_object attribute is missing.

    def __call__(self, environ, start_response):
        """The main call handler that is called to return a response"""
        log_debug = self._pylons_log_debug

        # Keep a local reference to the req/response objects
        self._py_object = environ['pylons.pylons']

It shouldn't be, unless you've overridden the WSGIController.__call__. From WSGIController: The Pylons decorators and WSGIController keep a reference to all the global context objects like request/response/session on this one object for efficiency purposes.

From what I can read in the source, it seems that most objects in
Pylons are StackedObjectProxy objects.

Yep, but this has direct reference to the actual objects. It's not a big deal performance wise unless you need to access the global request/ response or tmpl_context (c) a *lot* in a loop.

I try to get through this rigmarole merely to use @pylons.decorators in the code in lib/ directory, because the decorators have to get an object

with _py_object attr as the first argument (obviously, typically in
pylons that's 'self').

Cheers,
Ben

Those decorators will be there unless you fail to let the base classes (WSGIController) __call__ be called.

smime.p7s
Description: S/MIME cryptographic signature