A RetroSearch Logo

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

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2004-April/044215.html below:

[Python-Dev] Re: Candidate Function Decorator

[Python-Dev] Re: Candidate Function DecoratorPhillip J. Eby pje at telecommunity.com
Tue Apr 13 13:54:58 EDT 2004
At 01:40 PM 4/13/04 -0400, Terry Reedy wrote:

>"Raymond Hettinger" <raymond.hettinger at verizon.net>  [cc'ed]:
>
> >I worked out the details for binding constants and posted a recipe
>       http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940
>
>I have the impression that it is proposed that the function f will *not*
>yet be bound to its name (f.func_name) in its environment at the time the
>decorator is called.  If so, f.func_name will not appear in env unless you
>separately add it.  If you do add it, then I would think that recursive
>functions would be bound to themselves and recursive calls would also go
>faster, just as with calls to builtins, etc.
>
>The only obvious downside to me is that the circular ref would keep
>function around until gc'ed, but that is why gc was added ;-).

You'd have to follow a more complex process to set that up.  First, you'd 
create a code object with the function-constant filled in as None, then 
create a function object from it.  Then, you create a second code object 
containing the new function object in its constants.  Finally, you assign 
the new code object to the new function's func_code attribute.


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