13, 2010 10:07 AM
To: Eric Snow
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Proposed tweaks to functools.wraps
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote:
> Actually, what is the problem with having all decorators add a __decorated__
> to the function that ultimately gets re
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote:
> Actually, what is the problem with having all decorators add a __decorated__
> to the function that ultimately gets returned, pointing to the function they
> decorated? I guess I never saw that discussion. Perhaps set it to None when
> the d
=verio@python.org
[mailto:python-dev-bounces+esnow=verio@python.org] On Behalf Of Nick Coghlan
Sent: Tuesday, August 10, 2010 8:31 PM
To: python-dev@python.org
Subject: [Python-Dev] Proposed tweaks to functools.wraps
Based on a pair of tracker issues (#3445 and #9396) I'm considering a
c
On 8/11/2010 5:37 PM, Terry Reedy wrote:
> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>
>> The ability to introspect is basic to Python's design.
>> Objects know their class, functions know their code objects,
>> bound methods know both their underlying function,
>> classes know their own clas
On Aug 11, 2010, at 3:28 PM, Benjamin Peterson wrote:
> 2010/8/11 Raymond Hettinger :
>>
>> On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
>>
>>> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>>>
The ability to introspect is basic to Python's design.
Objects know their class, funct
On Wed, 2010-08-11 at 13:10 +1000, Nick Coghlan wrote:
> On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson
> wrote:
> > which would require ignoring the absence of __annotations__.
>
> It turns out the patch that added __annotations__ support also made a
> change to make all of the copied attr
2010/8/11 Raymond Hettinger :
>
> On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
>
>> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>>
>>> The ability to introspect is basic to Python's design.
>>> Objects know their class, functions know their code objects,
>>> bound methods know both their unde
On Aug 11, 2010, at 2:37 PM, Terry Reedy wrote:
> On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
>
>> The ability to introspect is basic to Python's design.
>> Objects know their class, functions know their code objects,
>> bound methods know both their underlying function,
>> classes know their
On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan wrote:
> However, as I noted before, these kinds of scenario are the reason we
> decided that building this feature directly into the decorator
> machinery wasn't a good idea.
I agree. I was just replying to Steven's response to my post. :)
Schiavo
On 8/11/2010 3:16 PM, Raymond Hettinger wrote:
The ability to introspect is basic to Python's design.
Objects know their class, functions know their code objects,
bound methods know both their underlying function,
classes know their own class dictionary, etc.
Should iterators know their iterab
On Thu, Aug 12, 2010 at 12:12 AM, Simon Cross
wrote:
> Yes. But it's more common for the original function to have be
> modified in some way. e.g.:
>
> def autodoc(f):
> f.__doc__ += document_args(f)
> return f
>
> @autodoc
> def f(x, y):
> """Add two numbers"""
> return x + y
>
> An
On Aug 11, 2010, at 6:00 AM, Steven D'Aprano wrote:
> @wraps(f)
> def func(*args):
>do_something()
>return f(*args)
>
> then func.__wrapped__ gives f. If f itself wraps (say) g, and g wraps h,
> then you have:
>
> func.__wrapped__ => f
> func.__wrapped__.__wrapped__ => g
> func.__wrapp
I think this is a good idea, because sometimes getting the innermost wrapped
function from a wrapper function is very useful. For example, when I use
inspect.getsource(), in most case, I want to get the source code of the
wrapped function, not the wrapper, because the wrapped function usually
conta
On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano wrote:
>> * The decorator returns the original function (I suppose a reference
>> to itself is okay?)
>
> There's no reason why a function can't have an attribute that refers to
> the function itself. It works fine:
Yes. But it's more common for th
On Wed, 11 Aug 2010 09:26:56 pm Simon Cross wrote:
> On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson
wrote:
> > Namespace conflict with what? I would prefer "wraps" unless it's
> > standardized as a behavior for all decorators.
>
> Having the original function available as __wrapped__ would be
On Wed, Aug 11, 2010 at 8:45 PM, Antoine Pitrou wrote:
> On Wed, 11 Aug 2010 12:30:40 +1000
> Nick Coghlan wrote:
>>
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exp
On Wed, Aug 11, 2010 at 9:26 PM, Simon Cross
wrote:
> On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson
> wrote:
>> Namespace conflict with what? I would prefer "wraps" unless it's
>> standardized as a behavior for all decorators.
>
> Having the original function available as __wrapped__ would
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson wrote:
> Namespace conflict with what? I would prefer "wraps" unless it's
> standardized as a behavior for all decorators.
Having the original function available as __wrapped__ would be really
cool, although I'm not quite sure what the behaviour
On Wed, 11 Aug 2010 12:30:40 +1000
Nick Coghlan wrote:
>
> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested
On Wed, Aug 11, 2010 at 1:22 PM, Steve Holden wrote:
> One of the things that's slightly irking about the decorator syntax is
> that a decorator is always called with exactly one argument, and that if
> you want to write a parameterized decorator you therefore end up writing
> a function that retu
On Tue, Aug 10, 2010 at 8:22 PM, Steve Holden wrote:
> One of the things that's slightly irking about the decorator syntax is
> that a decorator is always called with exactly one argument, and that if
> you want to write a parameterized decorator you therefore end up writing
> a function that retu
On 8/10/2010 10:58 PM, Nick Coghlan wrote:
> On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo wrote:
>>> The second (#9396) came up in the context of the new cache decorators
>>> added to functools, and allowing applications to choose their own
>>> caching strategies. I suggested exposing the origina
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson wrote:
> which would require ignoring the absence of __annotations__.
It turns out the patch that added __annotations__ support also made a
change to make all of the copied attributes optional.
So I'll be tidying up the implementation of that,
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson wrote:
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exposing the original (uncached)
>> function, and Raymond sugg
On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo wrote:
>> The second (#9396) came up in the context of the new cache decorators
>> added to functools, and allowing applications to choose their own
>> caching strategies. I suggested exposing the original (uncached)
>> function, and Raymond suggested
> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functoo
2010/8/10 Nick Coghlan :
> Based on a pair of tracker issues (#3445 and #9396) I'm considering a
> couple of adjustments to functools.wraps for 3.2.
>
> The first (#3445) is a request from ages ago to make update_wrapper
> more forgiving when it encounters a missing attribute. Instead of
> throwing
Based on a pair of tracker issues (#3445 and #9396) I'm considering a
couple of adjustments to functools.wraps for 3.2.
The first (#3445) is a request from ages ago to make update_wrapper
more forgiving when it encounters a missing attribute. Instead of
throwing AttributeError (as it does now), it
28 matches
Mail list logo
