Re: [Python-ideas] An easier syntax for writing decorators (& similar things)?
-----Original Message----- On 8 Oct 2007, at 10:57, Arnaud Delobelle wrote:
On Mon, October 8, 2007 4:33 am, Adam Atlas wrote:
When writing decorators especially when it's one that needs arguments other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
Following up post from 10/8/07.
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
, where prepartial is roughly the same as partial as you might expect:
(2) 1 def prepartial(func, *args, **keywords): 2 def newfunc(*fargs, **fkeywords): 3 newkeywords = keywords.copy() 4 newkeywords.update(fkeywords) 5 return func(*(fargs+ args), **newkeywords) 6 newfunc.func = func 7 newfunc.args = args 8 newfunc.keywords = keywords 9 return newfunc
Partial is the same outside of line 5:
(3) 5 return func(*(args + fargs), **newkeywords)
Results are the same:
-> f 1 f -> 2 2
Intriguing.
# Here's how to use it to create a decorator
@decorator_withargs def mydec(f, before='entering %s', after='%s returns %%s'): before = before % f.__name__ after = after % f.__name__ def decorated(*args, **kwargs): print before result = f(*args, **kwargs) print after % result return result return decorated
# Now I can decorate a function with my new decorator
@mydec(before='-> %s', after='%s -> %%s') def f(x): print x return x+1
Then
f(1)
-> f 1 f -> 2 2
-- Arnaud
I'm wondering, will Aaron ever realize that no-one understands his posts?
On Jan 23, 2008 1:44 AM, Aaron Brady castironpi@comcast.net wrote:
-----Original Message----- On 8 Oct 2007, at 10:57, Arnaud Delobelle wrote:
On Mon, October 8, 2007 4:33 am, Adam Atlas wrote:
When writing decorators especially when it's one that needs arguments other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
Following up post from 10/8/07.
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
, where prepartial is roughly the same as partial as you might expect:
(2) 1 def prepartial(func, *args, **keywords): 2 def newfunc(*fargs, **fkeywords): 3 newkeywords = keywords.copy() 4 newkeywords.update(fkeywords) 5 return func(*(fargs+ args), **newkeywords) 6 newfunc.func = func 7 newfunc.args = args 8 newfunc.keywords = keywords 9 return newfunc
Partial is the same outside of line 5:
(3) 5 return func(*(args + fargs), **newkeywords)
Results are the same:
-> f 1 f -> 2 2
Intriguing.
# Here's how to use it to create a decorator
@decorator_withargs def mydec(f, before='entering %s', after='%s returns %%s'): before = before % f.__name__ after = after % f.__name__ def decorated(*args, **kwargs): print before result = f(*args, **kwargs) print after % result return result return decorated
# Now I can decorate a function with my new decorator
@mydec(before='-> %s', after='%s -> %%s') def f(x): print x return x+1
Then
f(1)
-> f 1 f -> 2 2
-- Arnaud
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
This is like totally. cool. Like Mr. Delobelle's post on the decorator's and stuff was like, a simplified version of this:
decorator_withargs= partial( partial, prepartial )
Which is way cool, and I couldn't even understand, and like, wrap my brain around and stuff. Do uuuu understand? It?
-----Original Message----- From: python-ideas-bounces@python.org [mailto:python-ideas- bounces@python.org] On Behalf Of Guido van Rossum Sent: Wednesday, January 23, 2008 9:19 AM To: python-ideas@python.org Subject: Re: [Python-ideas] An easier syntax for writing decorators (&similar things)?
I'm wondering, will Aaron ever realize that no-one understands his posts?
On Jan 23, 2008 1:44 AM, Aaron Brady castironpi@comcast.net wrote:
-----Original Message----- On 8 Oct 2007, at 10:57, Arnaud Delobelle wrote:
On Mon, October 8, 2007 4:33 am, Adam Atlas wrote:
When writing decorators especially when it's one that needs
arguments
other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
Following up post from 10/8/07.
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
, where prepartial is roughly the same as partial as you might expect:
(2) 1 def prepartial(func, *args, **keywords): 2 def newfunc(*fargs, **fkeywords): 3 newkeywords = keywords.copy() 4 newkeywords.update(fkeywords) 5 return func(*(fargs+ args), **newkeywords) 6 newfunc.func = func 7 newfunc.args = args 8 newfunc.keywords = keywords 9 return newfunc
Partial is the same outside of line 5:
(3) 5 return func(*(args + fargs), **newkeywords)
Results are the same:
-> f 1 f -> 2 2
Intriguing.
# Here's how to use it to create a decorator
@decorator_withargs def mydec(f, before='entering %s', after='%s returns %%s'): before = before % f.__name__ after = after % f.__name__ def decorated(*args, **kwargs): print before result = f(*args, **kwargs) print after % result return result return decorated
# Now I can decorate a function with my new decorator
@mydec(before='-> %s', after='%s -> %%s') def f(x): print x return x+1
Then
f(1)
-> f 1 f -> 2 2
-- Arnaud
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 23 Jan 2008, at 09:44, Aaron Brady wrote:
-----Original Message----- On 8 Oct 2007, at 10:57, Arnaud Delobelle wrote:
On Mon, October 8, 2007 4:33 am, Adam Atlas wrote:
When writing decorators especially when it's one that needs arguments other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
Following up post from 10/8/07.
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
[where partial is as in functools and prepartial(f, x, y)(z, t) <=> f(z, t, x, y)]
Indeed, and if one restricts decorator_withargs to keyword arguments, one can simply define it as:
decorator_withargs = partial(partial, partial)
Which is the curry operator! So decorator_withargs is some sort of curry. In fact I had never realised before that this was a way to define curry (for functions with 2 arguments)
curry = partial(partial, partial)
[if f is a two-arguments function then curry(f)(x)(y) is f(x, y)]
This means that a meta-decorator (i.e. a decorator for decorators) is a kind of currying operator.
Intriguing.
!
When writing decorators especially when it's one that needs arguments other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
Following up post from 10/8/07.
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
[where partial is as in functools and prepartial(f, x, y)(z, t) <=> f(z, t, x, y)]
Indeed, and if one restricts decorator_withargs to keyword arguments, one can simply define it as:
decorator_withargs = partial(partial, partial)
I believe you can put -f- in the last pos'l argument and have this work.
def mydec( arg0, arg1, f, before='entering %s', after='%s returns %%s').
Which is the curry operator! So decorator_withargs is some sort of curry. In fact I had never realised before that this was a way to define curry (for functions with 2 arguments)
curry = partial(partial, partial)
[if f is a two-arguments function then curry(f)(x)(y) is f(x, y)]
This means that a meta-decorator (i.e. a decorator for decorators) is a kind of currying operator.
Intriguing.
!
When writing decorators especially when it's one that needs arguments other than the function to be wrapped, it often gets rather ugly...
[...]
Whhy not create a (meta-)decorator to do this? Something like:
[...]
To follow up on my untested suggestion, here's one that is tested:
# This metadecorator hasn't changed
def decorator_withargs(decf): def decorator(*args, **kwargs): def decorated(f): return decf(f, *args, **kwargs) return decorated return decorator
This is equivalent to: (1) decorator_withargs= partial( partial, prepartial )
[where partial is as in functools and prepartial(f, x, y)(z, t) <=> f(z, t, x, y)]
Indeed, and if one restricts decorator_withargs to keyword arguments, one can simply define it as:
decorator_withargs = partial(partial, partial)
I believe you can put -f- in the last pos'l argument and have this work.
def mydec( arg0, arg1, f, before='entering %s', after='%s returns %%s').
Which is the curry operator! So decorator_withargs is some sort of curry. In fact I had never realised before that this was a way to define curry (for functions with 2 arguments)
curry = partial(partial, partial)
[if f is a two-arguments function then curry(f)(x)(y) is f(x, y)]
This means that a meta-decorator (i.e. a decorator for decorators) is a kind of currying operator.
Intriguing.
!
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far, fkwar ) return sf return preg
We see how to rewrite this one?
On Jan 23, 2008 7:06 PM, Aaron Brady castironpi@comcast.net wrote:
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far, fkwar ) return sf return pregWe see how to rewrite this one?
The Python Ideas list is really intended as sort of a testing ground for potential PEPs. What is it that you're proposing to add to or remove from the language?
If you're just enjoying writing code in Python, comp.lang.python is a more appropriate place to post.
STeVe
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far,fkwar )
return sf return pregWe see how to rewrite this one?
The Python Ideas list is really intended as sort of a testing ground for potential PEPs. What is it that you're proposing to add to or remove from the language?
+1 on prepartial in functools.
On Jan 23, 2008 10:55 PM, Aaron Brady castironpi@comcast.net wrote:
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far,fkwar )
return sf return pregWe see how to rewrite this one?
The Python Ideas list is really intended as sort of a testing ground for potential PEPs. What is it that you're proposing to add to or remove from the language?
+1 on prepartial in functools.
So far, I've only seen this one use case for prepartial - and I'd rather have decorator_withargs itself than prepartial. Do you have any other use cases for prepartial (from real code somewhere)?
Currently, I'm -1 on adding prepartial to functools, and +0.5 on adding something like decorator_withargs.
STeVe
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far,fkwar )
return sf return pregWe see how to rewrite this one?
The Python Ideas list is really intended as sort of a testing ground for potential PEPs. What is it that you're proposing to add to or remove from the language?
+1 on prepartial in functools.
So far, I've only seen this one use case for prepartial - and I'd rather have decorator_withargs itself than prepartial. Do you have any other use cases for prepartial (from real code somewhere)?
Currently, I'm -1 on adding prepartial to functools, and +0.5 on adding something like decorator_withargs.
Are you also -1 on partial's being in functools?
On Jan 23, 2008 11:20 PM, Aaron Brady castironpi@comcast.net wrote:
def f( callback, *bar, **bkwar ): def preg ( callfore, *far, **fkwar ): sf= g( callback, callfore, bar, bkwar, far,fkwar )
return sf return pregWe see how to rewrite this one?
The Python Ideas list is really intended as sort of a testing ground for potential PEPs. What is it that you're proposing to add to or remove from the language?
+1 on prepartial in functools.
So far, I've only seen this one use case for prepartial - and I'd rather have decorator_withargs itself than prepartial. Do you have any other use cases for prepartial (from real code somewhere)?
Currently, I'm -1 on adding prepartial to functools, and +0.5 on adding something like decorator_withargs.
Are you also -1 on partial's being in functools?
Not that it matters, since it's already there, but no, I wasn't. In fact, the presence of partial is a big reason not to need prepartial -- most existing use cases are already covered by using partial. As Arnaud pointed out, if you restrict decorator_withargs to keyword arguments, you don't even need prepartial, you can just use partial itself. Thus, I don't see prepartial as really covering many new use cases. If you'd like to convince me otherwise, you're going to need to post some use cases from real code.
STeVe
+1 on prepartial in functools.
So far, I've only seen this one use case for prepartial - and I'd rather have decorator_withargs itself than prepartial. Do you have any other use cases for prepartial (from real code somewhere)?
Currently, I'm -1 on adding prepartial to functools, and +0.5 on adding something like decorator_withargs.
Are you also -1 on partial's being in functools?
Not that it matters, since it's already there, but no, I wasn't.
Good. I was. It got in.
In fact, the presence of partial is a big reason not to need prepartial
Fallacy.
-- most existing use cases are already covered by using partial.
Lacks citation.
As Arnaud pointed out, if you restrict decorator_withargs to keyword arguments,
You don't.
Thus, I don't see prepartial as really covering many new use cases.
Syllogism:
A -> B A _____ B
Thus what again?
If you'd like to convince me otherwise, you're going to need to post some use cases from real code.
curry= partial( partial, prepartial ) [1]
Steven Bethard wrote: [after suggesting that prepartial doesn't gain us much over what we already have with functools.partial]
If you'd like to convince me otherwise, you're going to need to post some use cases from real code.
On Jan 24, 2008 1:36 PM, Aaron Brady castironpi@comcast.net wrote:
curry= partial( partial, prepartial ) [1]
I don't consider that a use case, or real code. ;-) Yes, you can construct curry with it. But what do you want to use curry for? Show me some actual Python packages that use the curry function (or your prepartial function) and then we can talk.
STeVe
I don't consider that a use case, or real code. ;-) Yes, you can construct curry with it. But what do you want to use curry for? Show me some actual Python packages that use the curry function (or your prepartial function) and then we can talk.
That's a, who uses partial?
I don't consider that a use case, or real code. ;-) Yes, you can construct curry with it. But what do you want to use curry for? Show me some actual Python packages that use the curry function (or your prepartial function) and then we can talk.
Original function: 1. urlparse( urlstring[, default_scheme[, allow_fragments]]) 2. urlretrieve( url[, filename[, reporthook[, data]]])
Prepartial in action: 1. parseA= prepartial( 'ftp', False ) 2. retrieveA= prepartial( 'temp.htm', callbackA )
Equivalent: 1. parseAB= partial( default_scheme= 'ftp', allow_fragments= True ) 2. retrieveAB= partial( filename= 'temp.htm', reporthook= callbackA )
Equivalent calls: 1. parseA( 'www.cwi.nl/%7Eguido/Python.html' ) 2. retrieveA( 'http://python.org/' )
Motto: - Programmer time is important - The stdlib does not contain application-level design
Aaron, I don't know who you are, and I don't know what you are doing here, but this type of post with monosyllabic answers really pisses me off. I suggest you take it somewhere else, or learn to have a normal discussion. Where did you learn this type of behavior? If you think this is normal or even acceptable, well, it isn't. Also, you seem to be abusing this list for a purpose it isn't meant for. You risk being kicked off.
On Jan 24, 2008 12:36 PM, Aaron Brady castironpi@comcast.net wrote:
+1 on prepartial in functools.
So far, I've only seen this one use case for prepartial - and I'd rather have decorator_withargs itself than prepartial. Do you have any other use cases for prepartial (from real code somewhere)?
Currently, I'm -1 on adding prepartial to functools, and +0.5 on adding something like decorator_withargs.
Are you also -1 on partial's being in functools?
Not that it matters, since it's already there, but no, I wasn't.
Good. I was. It got in.
In fact, the presence of partial is a big reason not to need prepartial
Fallacy.
-- most existing use cases are already covered by using partial.
Lacks citation.
As Arnaud pointed out, if you restrict decorator_withargs to keyword arguments,
You don't.
Thus, I don't see prepartial as really covering many new use cases.
Syllogism:
A -> B A _____ B
Thus what again?
If you'd like to convince me otherwise, you're going to need to post some use cases from real code.
curry= partial( partial, prepartial ) [1]
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
The personal dispute is tabled.
Confer: http://mail.python.org/pipermail/python-ideas/2008-January/001357.html (Thu Jan 24 23:26:00 CET 2008).
participants (4)
-
Aaron Brady -
Arnaud Delobelle -
Guido van Rossum -
Steven Bethard