=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
couple
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow es...@verio.net 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
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 es...@verio.net wrote:
Actually, what is the problem with having all decorators add a __decorated__
to the function that ultimately
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org 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
On Wed, Aug 11, 2010 at 9:26 PM, Simon Cross
hodgestar+python...@gmail.com wrote:
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson benja...@python.org
wrote:
Namespace conflict with what? I would prefer wraps unless it's
standardized as a behavior for all decorators.
Having the original
On Wed, Aug 11, 2010 at 8:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 11 Aug 2010 12:30:40 +1000
Nick Coghlan ncogh...@gmail.com 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
On Wed, 11 Aug 2010 09:26:56 pm Simon Cross wrote:
On Wed, Aug 11, 2010 at 4:39 AM, Benjamin Peterson
benja...@python.org 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
On Wed, Aug 11, 2010 at 3:00 PM, Steven D'Aprano st...@pearwood.info 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
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
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
On Thu, Aug 12, 2010 at 12:12 AM, Simon Cross
hodgestar+python...@gmail.com 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
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
On Wed, Aug 11, 2010 at 11:21 PM, Nick Coghlan ncogh...@gmail.com 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
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 own
2010/8/11 Raymond Hettinger raymond.hettin...@gmail.com:
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
On Wed, 2010-08-11 at 13:10 +1000, Nick Coghlan wrote:
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson benja...@python.org
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
On Aug 11, 2010, at 3:28 PM, Benjamin Peterson wrote:
2010/8/11 Raymond Hettinger raymond.hettin...@gmail.com:
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
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 class
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),
2010/8/10 Nick Coghlan ncogh...@gmail.com:
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
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
On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo mer...@netwok.org 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
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson benja...@python.org 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
On Wed, Aug 11, 2010 at 12:39 PM, Benjamin Peterson benja...@python.org 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
On 8/10/2010 10:58 PM, Nick Coghlan wrote:
On Wed, Aug 11, 2010 at 12:48 PM, Éric Araujo mer...@netwok.org 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
On Tue, Aug 10, 2010 at 8:22 PM, Steve Holden st...@holdenweb.com 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
On Wed, Aug 11, 2010 at 1:22 PM, Steve Holden st...@holdenweb.com 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
27 matches
Mail list logo
