decorators - would be nice if...

[Ken Seehart]

Almost every time I use decorators, I find myself wishing I had access
to the local namespace of the context from which the decorator is
executed. In practice, decorator is being applied to a method, so the
namespace in question would be the dictionary of the class being created.

Similarly, before decorators were around, I often found myself lamenting
the fact that a class is not created until after it's scope is
completed, since this makes certain kinds of metaprogramming more
difficult. But after digging deeper, I realized why it is the way it
is, so I don't complain about that.

But it would have been a simple thing to add an argument 'locals' to the
decorator specification. It's somewhat more difficult to add that now
because of compatibility issues, but perhaps there is a way to get the
same effect.

I can work around all of this by making my decorators just store data to
be processed by a metaclass, but that solution is less elegant. Also,
it has the slight disadvantage of requiring the use of a metaclass which
would otherwise not be necessary. I prefer to save metaclass
implementation as a last resort for various reasons (e.g. there does not
seem to be a good way to use multiple metaclasses in a class hierarchy,
and more generally you can't stack them on top of each other (you can
only have one metaclass per class)).

Thoughts?

- Ken

 

[Diez B. Roggisch]

Almost every time I use decorators, I find myself wishing I had access
to the local namespace of the context from which the decorator is
executed. In practice, decorator is being applied to a method, so the
namespace in question would be the dictionary of the class being created.

You can access the instance.

def decorator(method):
def _d(self, *args, **kwargs):
print self.__dict__
return method(self, *args, **kwargs)

return _d

class Foo(object):

@decorator
def bar(self, a, b):
print "bar"


f = Foo()

f.bar(1, 2)

So what exactly it is you are missing? The method's locals()?

And could you explain *why* you are missing this?


Diez

 

[Carl Banks]

[snip]
(e.g. there does not

seem to be a good way to use multiple metaclasses in a class hierarchy,
and more generally you can't stack them on top of each other (you can
only have one metaclass per class)).

Thoughts?

If "stacking" metaclasses (whatever that means) is a possible approach
to your problem, you might want to ask yourself if you're trying to be
too clever.

Would you like to give us an example of a decorator you think would
benefit from having access to local namespace? We might be able to
suggest other possibilities.


Carl Banks