On 2:59 PM, Ethan Furman wrote:
> def __call__(self, func=None):
> if func is None:
> return self._call()
> self.func = func
> return self
> def _call(self):
> print("\n" + self.char * 50)
> self.func()
> print(self.char * 50 +
Lie Ryan wrote:
> Simplicity is one, using @decor() means you have at least three-level
> nested functions, which means the code is likely to be very huge and
> perhaps unnecessarily.
>
If you don't like the extra level of function nesting that you get from
returning a decorator factory instea
Ian Kelly wrote:
@enclose
def test5(string, func):
print(func(string))
test5('broken', func=str.upper)
Yes, that is a limitation -- one loses the func keyword for the
decorated function. If I were to actually use this, I'd probably go
with '_func' as the keyword.
~Ethan~
PS
Thanks f
On Wed, Jun 29, 2011 at 3:29 PM, Ethan Furman wrote:
> 8<
> class enclose(object):
> func = None
> def __init__(self, char='#'):
> self.char = char
> if callable(char): # was a function passed in directly?
>
Ian Kelly wrote:
On Wed, Jun 29, 2011 at 1:30 PM, Ethan Furman wrote:
How about just having one bit of code that works either way?
How would you adapt that code if you wanted to be able to decorate a
function that takes arguments?
8<--
On Wed, Jun 29, 2011 at 1:30 PM, Ethan Furman wrote:
> How about just having one bit of code that works either way?
How would you adapt that code if you wanted to be able to decorate a
function that takes arguments?
This also won't work if the argument to the decorator is itself a
callable, such
John Posner wrote:
Investigating how this fact fit in with the current thread, I came up
with an alternative to the three levels of "def" (pronounced "three
levels of death"). Following is code for two decorators:
* the first one encloses the output of a function with lines of "#"
characters, an
On 2:59 PM, Lie Ryan wrote:
>> Can any of you guys explain me advantages and disadvantages of
>> using each of them
> Simplicity is one, using @decor() means you have at least three-level
> nested functions, which means the code is likely to be very huge and
> perhaps unnecessarily.
Bruce Eckel po
okie i agree with your comment, if the case is simple we would
prefer not to make it complex but if required there would be nor harm in
using decorators with Arguments
Thanks,
J
--- On Tue, 28/6/11, Lie Ryan wrote:
From: Lie Ryan
Subject: Re: Using decorators with argument in
yes for this case you will have to use @memoize() as all the arguments are
optional ...
Thanks,
J
--- On Tue, 28/6/11, Ian Kelly wrote:
From: Ian Kelly
Subject: Re: Using decorators with argument in Python
To: "Jigar Tanna"
Cc: python-list@python.org
Date: Tuesday, 28 June, 2011
Jigar Tanna writes:
> where I came across a special case of using arguments with decorators
A decorator is a function which takes exactly one parameter, and returns
a function based on that parameter.
http://docs.python.org/glossary.html#term-decorator>
http://docs.python.org/reference/
On Tue, Jun 28, 2011 at 10:52 AM, Jigar Tanna
wrote:
> coming across to certain views from people, it is not a good practice
> to use
> decorators with arguments (i.e. @memoize() ) and instead it is good to
> just
> use @memoize. Can any of you guys explain me advantages and
> disadvantages of
> u
On 06/29/2011 02:52 AM, Jigar Tanna wrote:
> coming across to certain views from people, it is not a good practice
> to use
> decorators with arguments (i.e. @memoize() ) and instead it is good to
> just
> use @memoize. Can any of you guys explain me advantages and
> disadvantages of
> using each
I am new to Python and Django, was going through the concept of
decorators
where I came across a special case of using arguments with decorators
Below is the code for memoization where I was looking at the
concept...
cache = {}
def get_key(function, *args, **kw) :
key = '%s. %s: ' % (function.
14 matches
Mail list logo
