A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/047856.html below:

[Python-Dev] Re: Decorator order implemented backwards?

[Python-Dev] Re: Decorator order implemented backwards?Jack Diederich jack at performancedrivers.com
Mon Aug 16 05:45:43 CEST 2004
On Sun, Aug 15, 2004 at 08:46:03PM +0100, Mark Russell wrote:
> Here's my current attempt at describing the semantics in the reference
> manual:
> 
>     A function definition may be wrapped by one or more decorator
>     expressions. Decorator expressions are evaluated when the function
>     is defined, in the scope that contains the function definition.
>     The result must be a callable, which is invoked with the function
>     object as the only argument.  The returned value is bound to the
>     function name instead of the function object.  Multiple decorators
>     are applied in nested fashion.  For example, the following code:
> 
> 	@f1(arg)
> 	@f2
> 	def func(): pass
> 
>     is equivalent to:
> 
> 	def func(): pass
> 	func = f1(arg)(f2(func))

Is func actually defined when f1 and f2 are called?  Looking at the
code the VAR_STORE doesn't happen until after the decorators are added.
[but I'm no expert on bytecode].  This won't matter for sane decorators
but we're talking about the strange cases already.  Reading the @ code top
to bottom you would not expect func to be defined, but if you want it to be
strictly like the 'func = decorate(func)' translation is should be.

My patch to add support for class decorators defines func before the
decorators as a side effect of moving Mark's decorator code out of 
com_funcdef (and yes, that was a plug).

-Jack


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4