Peter Otten, Cameron Simpson, thank you for your detailed replies :-) I
confess, I didn't quite understand all you were saying. (Still only an
intermediate-level programmer.) But Cameron what you said questioning my
use of decorators and maybe a class instead got me thinking. I realized
what I need
Christopher de Vidal wrote:
> Help please? Creating an MQTT-to-Firestore bridge and I know a decorator
> would help but I'm stumped how to create one. I've used decorators before
> but not with arguments.
>
> The Firestore collection.on_snapshot() method invokes a callback and sends
> it three pa
On 14May2020 08:28, Christopher de Vidal wrote:
Help please? Creating an MQTT-to-Firestore bridge and I know a decorator
would help but I'm stumped how to create one. I've used decorators before
but not with arguments.
The Firestore collection.on_snapshot() method invokes a callback and sends
i
Jason Friedman writes:
> Found an answer:
> https://wiki.python.org/moin/PythonDecoratorLibrary#Function_Timeout
That is pretty limited since signal handlers always run in the main
thread, and that wrapper takes over the sigalarm handler which some
other part of the program might also want to use
> But, I'd like to expand this to take some generic code, not just a
> shell command, and terminate it if it does not return quickly.
>
> @time_limiter
> def generic_function(arg1, arg2, time_limit=10):
> do_some_stuff()
> do_some_other_stuff()
> return val1, val2
>
> If generic_functio
On 11/15/2014 8:24 AM, Marko Rauhamaa wrote:
I'd take top-posting if I were enlightened about how decorators could be
valuable.
Here is part of the original rationale.
@deco(arg)
def f: suite
is (for this discussion) equivalent to
def f: suite
f = deco(arg)(f)
The latter requires writing '
Richard Riehle wrote:
> Decorators are new in Python, so there are not a lot of people using them.
The principle of decorators themselves is as old as Python itself. You could
implement them as far back as Python 1.5, if not older:
[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09
On 2014-11-15, Marko Rauhamaa wrote:
> Tim Chase :
>
>> And decorators are used pretty regularly in just about every code-base
>> that I've touched (I've been programming in Python since early 2004,
>> so I've maintained pre-2.4 code without decorators and then brought it
>> forward to 2.4 where d
Mark Lawrence :
> On 15/11/2014 07:42, Richard Riehle wrote:
>> When I discovered them, I instantly saw how they could be valuable.
>
> Would you please be kind enough to get a PhD in interspersing your
> replies or bottom posting rather than top posting, thank you.
I'd take top-posting if I were
On 15/11/2014 07:42, Richard Riehle wrote:
Mayank,
Thanks. I have only been using Python for about four years, so there
are features I have only recently discovered. Decorators are one of
them. So far, I encounter other Python users who are also unfamiliar
with them. When I discovered them,
Mayank,
Thanks. I have only been using Python for about four years, so there are
features I have only recently discovered. Decorators are one of them. So
far, I encounter other Python users who are also unfamiliar with them.
When I discovered them, I instantly saw how they could be valuable.
Tim Chase :
> And decorators are used pretty regularly in just about every code-base
> that I've touched (I've been programming in Python since early 2004,
> so I've maintained pre-2.4 code without decorators and then brought it
> forward to 2.4 where decorators were usable).
Funny. My experience
On 2014-11-14 18:19, Richard Riehle wrote:
> Decorators are new in Python, so there are not a lot of people
> using them.
Um...they were introduced in 2.4 which was released in late 2004. So
they've only been around for about (almost exactly) a decade. Not
sure that qualifies as "new in Python"
Decorators were there in Python 2.4, released in 2005. Not exactly new.
On Sat Nov 15 2014 at 7:51:11 AM Richard Riehle wrote:
> On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
> > Richard Riehle :
> >
> > > I find that not a lot of Python user really appreciate the power of
On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
> Richard Riehle :
>
> > I find that not a lot of Python user really appreciate the power of
> > decorators.
>
> Well, I don't.
>
> All it means is that I've never seen a use of decorators that has
> enhanced the code. Once I "
Mark Lawrence :
> Perhaps this helps
> http://blog.dscpl.com.au/2014/01/how-you-implemented-your-python.html ?
Thanks, but sorry, it didn't. I couldn't even relate to the supposed
WSGI craze.
I'm yet to face the situation where a colleague would point out, "See
how elegantly you could have done
On 14/11/2014 22:18, Marko Rauhamaa wrote:
Richard Riehle :
I find that not a lot of Python user really appreciate the power of
decorators.
Well, I don't.
All it means is that I've never seen a use of decorators that has
enhanced the code. Once I "see the light," I'll have no problem changin
On 2013-10-25 22:01, Peter Otten wrote:
> > from functools import wraps
> > class require_keys:
> > def __init__(self, *keys):
> > self.keys = keys
> > def __call__(decorator_self, fn):
> > @wraps(fn)
> > def result_fn(method_self, *args, **kwargs):
> > # import pdb; pdb.set_t
Tim Chase wrote:
> Given the following example 2.7 code:
>
> from functools import wraps
> class require_keys:
> def __init__(self, *keys):
> self.keys = keys
> def __call__(decorator_self, fn):
> @wraps(fn)
> def result_fn(method_self, *args, **kwargs):
> # import pdb; pdb.
- Original Message -
> Jean-Michel Pichavant writes:
>
> > - Original Message -
> >> Jean-Michel Pichavant wrote:
> > [snip]
> >> One minor note, the style of decorator you are using loses the
> >> docstring
> >> (at least) of the original function. I would add the
> >> @functoo
Terry Reedy於 2012年9月15日星期六UTC+8上午4時40分32秒寫道:
> 2nd try, hit send button by mistake before
>
>
>
> On 9/14/2012 5:28 AM, Jean-Michel Pichavant wrote:
>
>
>
> > Decorators are very popular so I kinda already know that the fault is
>
> > mine. Now to the reason why I have troubles writing them,
Jean-Michel Pichavant writes:
> - Original Message -
>> Jean-Michel Pichavant wrote:
> [snip]
>> One minor note, the style of decorator you are using loses the
>> docstring
>> (at least) of the original function. I would add the
>> @functools.wraps(func)
>> decorator inside your decorator
Chris Angelico於 2012年9月18日星期二UTC+8下午9時25分04秒寫道:
> On Tue, Sep 18, 2012 at 11:19 PM, Neil Cerutti wrote:
>
> > On 2012-09-14, Chris Angelico wrote:
>
> >> But then again, who actually ever needs fibonacci numbers?
>
> >
>
> > If it should happen that your question is not facetious:
>
> >
>
>
On Tue, Sep 18, 2012 at 11:19 PM, Neil Cerutti wrote:
> On 2012-09-14, Chris Angelico wrote:
>> But then again, who actually ever needs fibonacci numbers?
>
> If it should happen that your question is not facetious:
>
> http://en.wikipedia.org/wiki/Fibonacci_number#Applications
It wasn't entirel
On 2012-09-14, Chris Angelico wrote:
> But then again, who actually ever needs fibonacci numbers?
If it should happen that your question is not facetious:
http://en.wikipedia.org/wiki/Fibonacci_number#Applications
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Am 15.09.2012 16:18 schrieb 8 Dihedral:
The concept of decorators is just a mapping from a function
... or class ...
> to another function
... or any other object ...
> with the same name in python.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
- Original Message -
> Jean-Michel Pichavant wrote:
[snip]
> One minor note, the style of decorator you are using loses the
> docstring
> (at least) of the original function. I would add the
> @functools.wraps(func)
> decorator inside your decorator.
Is there a way to not loose the funct
On Sep 15, 6:30 am, Terry Reedy wrote:
> > On 13Sep2012 18:58, alex23 wrote:
> > | On Sep 14, 3:54 am, Jean-Michel Pichavant
> > | wrote:
> > | > I don't like decorators, I think they're not worth the mental effort.
> > |
> > | Because passing a function to a function is a huge cognitive burden?
David Hutto於 2012年9月15日星期六UTC+8下午6時04分28秒寫道:
> On Sat, Sep 15, 2012 at 5:45 AM, 8 Dihedral
>
> wrote:
>
> > Steven D'Aprano於 2012年9月15日星期六UTC+8上午7時39分28秒寫道:
>
> >> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
>
> >>
>
> >>
>
> >>
>
> >> > If only there were a conceptually simple
On Sat, Sep 15, 2012 at 5:45 AM, 8 Dihedral
wrote:
> Steven D'Aprano於 2012年9月15日星期六UTC+8上午7時39分28秒寫道:
>> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
>>
>>
>>
>> > If only there were a conceptually simpler way to do this. Actually,
>>
>> > there is. I give you: muman than humanetadec
Steven D'Aprano於 2012年9月15日星期六UTC+8上午7時39分28秒寫道:
> On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
>
>
>
> > If only there were a conceptually simpler way to do this. Actually,
>
> > there is. I give you: metadecorators!
>
> [code snipped but shown below]
>
> > Which I think is certain
[Sorry, my Firefox destroyed the indent...
Am 14.09.2012 22:29 schrieb Terry Reedy:
In other words
def make_wrapper(func, param):
def wrapper(*args, **kwds):
for i in range(param):
func(*args, **kwds)
return wrapper
def f(x): print(x)
f = make_wrapper(f, 2)
f('simple')
# is simpler, at least
Dwight Hutto wrote at 2012-9-14 23:42 -0400:
> ...
>Reduce redundancy, is argumentative.
>
>To me, a decorator, is no more than a logging function. Correct me if
>I'm wrong.
Well, it depends on how you are using decorators and how complex
your decorators are. If what you are using as decorating fu
On Fri, Sep 14, 2012 at 2:40 AM, Dieter Maurer wrote:
>> On Sep 14, 3:54 am, Jean-Michel Pichavant
>> wrote:
>>> I don't like decorators, I think they're not worth the mental effort.
>
> Fine.
>
> I like them because they can vastly improve reusability and drastically
> reduce redundancies (which
On Sep 14, 6:05 am, Tim Chase wrote:
> On 09/14/12 07:01, Steven D'Aprano wrote:> [snip timeout class]
>
> > Holy over-engineering Batman!!!
>
> > No wonder you don't think much of decorators,
>
> [snip]
>
> > Most of my decorator functions are under a dozen lines. And that's the
> > complicated o
On Fri, 14 Sep 2012 15:16:47 -0600, Ian Kelly wrote:
> If only there were a conceptually simpler way to do this. Actually,
> there is. I give you: metadecorators!
[code snipped but shown below]
> Which I think is certainly easier to understand than the nested
> functions approach.
Maybe for you
Jean-Michel Pichavant wrote:
[snip]
> Ultimately, the goal is to have something like
>
> @timeout(2)
> def doAction1
>
> @timeout(4)
> def doAction2
[snip]
> Here's Steven example:
>
> # Untested!
> def timeout(t=15):
> # Decorator factory. Return a decorator to actually do the work.
>
On 14 September 2012 18:30, Chris Angelico wrote:
> On Sat, Sep 15, 2012 at 2:15 AM, andrea crotti
> wrote:
> > The poor algorithm is much more close to the mathematical definition
> > than the smarter iterative one.. And in your second version you
> > include some ugly caching logic inside it,
On Fri, Sep 14, 2012 at 2:29 PM, Terry Reedy wrote:
> For a simple, unparameterized wrapper, the difficulty is entirely in the
> wrapper maker. It must define the final wrapper as a nested function and
> return it*. It is irrelevant whether the wrapper maker is used with pre-def
> decorator syntax
On 9/14/2012 4:29 PM, Terry Reedy wrote:
On 9/13/2012 10:12 PM, Cameron Simpson wrote:
On 13Sep2012 18:58, alex23 wrote:
| On Sep 14, 3:54 am, Jean-Michel Pichavant
| wrote:
| > I don't like decorators, I think they're not worth the mental effort.
|
| Because passing a function to a function i
2nd try, hit send button by mistake before
On 9/14/2012 5:28 AM, Jean-Michel Pichavant wrote:
Decorators are very popular so I kinda already know that the fault is
mine. Now to the reason why I have troubles writing them, I don't
know. Every time I did use decorators, I spent way too much time
On 9/14/2012 5:28 AM, Jean-Michel Pichavant wrote:
Decorators are very popular so I kinda already know that the fault is mine. Now
to the reason why I have troubles writing them, I don't know. Every time I did
use decorators, I spent way too much time writing it (and debugging it).
--
Terry
On 9/13/2012 10:12 PM, Cameron Simpson wrote:
On 13Sep2012 18:58, alex23 wrote:
| On Sep 14, 3:54 am, Jean-Michel Pichavant
| wrote:
| > I don't like decorators, I think they're not worth the mental effort.
|
| Because passing a function to a function is a huge cognitive burden?
For parameter
On Sat, Sep 15, 2012 at 2:15 AM, andrea crotti
wrote:
> The poor algorithm is much more close to the mathematical definition
> than the smarter iterative one.. And in your second version you
> include some ugly caching logic inside it, so why not using a
> decorator then?
I learned Fibonacci as
Chris Angelico於 2012年9月14日星期五UTC+8下午10時41分06秒寫道:
> On Sat, Sep 15, 2012 at 12:12 AM, andrea crotti
>
> wrote:
>
> > def fib(n):
>
> > if n <= 1:
>
> > return 1
>
> > return fib(n-1) + fib(n-2)
>
> >
>
> > @memoize
>
> > def fib_memoized(n):
>
> > if n <= 1:
>
> >
2012/9/14 Chris Angelico :
>
> Trouble is, you're starting with a pretty poor algorithm. It's easy to
> improve on what's poor. Memoization can still help, but I would start
> with a better algorithm, such as:
>
> def fib(n):
> if n<=1: return 1
> a,b=1,1
> for i in range(1,
- Original Message -
> On Fri, 14 Sep 2012 15:22:26 +0200, Jean-Michel Pichavant wrote:
>
> > Here's Steven example:
> >
> > # Untested!
> > def timeout(t=15):
> > # Decorator factory. Return a decorator to actually do the
> > work. if
> > FPGA:
> > t *= 3
> > def
On Fri, 14 Sep 2012 15:22:26 +0200, Jean-Michel Pichavant wrote:
> Here's Steven example:
>
> # Untested!
> def timeout(t=15):
> # Decorator factory. Return a decorator to actually do the work. if
> FPGA:
> t *= 3
> def decorator(func):
> @functools.wraps(func)
>
On Sat, Sep 15, 2012 at 12:12 AM, andrea crotti
wrote:
> def fib(n):
> if n <= 1:
> return 1
> return fib(n-1) + fib(n-2)
>
> @memoize
> def fib_memoized(n):
> if n <= 1:
> return 1
> return fib_memoized(n-1) + fib_memoized(n-2)
>
>
> The second fibonacci looks exac
I think one very nice and simple example of how decorators can be used is this:
def memoize(f, cache={}, *args, **kwargs):
def _memoize(*args, **kwargs):
key = (args, str(kwargs))
if not key in cache:
cache[key] = f(*args, **kwargs)
return cache[key]
r
- Original Message -
> Jean-Michel Pichavant wrote:
>
> > I wrote the following one, used to decorate any function that
> > access
> > an equipment, it raises an exception when the timeout expires. The
> > timeout is adapted to the platform, ASIC of FPGA so people don't
> > need
> > to
On 09/14/12 07:01, Steven D'Aprano wrote:
> [snip timeout class]
>
> Holy over-engineering Batman!!!
>
> No wonder you don't think much of decorators,
[snip]
> Most of my decorator functions are under a dozen lines. And that's the
> complicated ones!
As are mine, and a sizable chunk of those
Am 14.09.2012 11:28, schrieb Jean-Michel Pichavant:
Decorators are very popular so I kinda already know that the
fault is mine. Now to the reason why I have troubles writing
them, I don't know. Every time I did use decorators, I spent
way too much time writing it (and debugging it).
I wrote the
On Fri, 14 Sep 2012 11:28:22 +0200, Jean-Michel Pichavant wrote:
> PS : Here's the decorator, just to give you an idea about how it looks.
> Small piece of code, but took me more than 2 hours to write it. I
> removed some sensible parts so I don't expect it to run.
[snip timeout class]
Holy over
Jean-Michel Pichavant wrote:
> I wrote the following one, used to decorate any function that access
> an equipment, it raises an exception when the timeout expires. The
> timeout is adapted to the platform, ASIC of FPGA so people don't need
> to specify everytime one timeout per platform.
>
> I
- Original Message -
> On Sep 14, 3:54 am, Jean-Michel Pichavant
> wrote:
> > I don't like decorators, I think they're not worth the mental
> > effort.
>
> Because passing a function to a function is a huge cognitive burden?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
I
> On Sep 14, 3:54 am, Jean-Michel Pichavant
> wrote:
>> I don't like decorators, I think they're not worth the mental effort.
Fine.
I like them because they can vastly improve reusability and drastically
reduce redundancies (which I hate). Improved reusability and
reduced redundancies can make a
On Sep 14, 12:12 pm, Cameron Simpson wrote:
> On 13Sep2012 18:58, alex23 wrote:
> | On Sep 14, 3:54 am, Jean-Michel Pichavant | wrote:
> | > I don't like decorators, I think they're not worth the mental effort.
> |
> | Because passing a function to a function is a huge cognitive burden?
>
> It is
On 13Sep2012 18:58, alex23 wrote:
| On Sep 14, 3:54 am, Jean-Michel Pichavant
| wrote:
| > I don't like decorators, I think they're not worth the mental effort.
|
| Because passing a function to a function is a huge cognitive burden?
It is for me when I'm _writing_ the decorator:-) But if I get
On Monday, November 21, 2011 10:44:34 PM UTC+8, Andrea Crotti wrote:
> With one colleague I discovered that the decorator code is always
> executed, every time I call
> a nested function:
>
> def dec(fn):
> print("In decorator")
> def _dec():
> fn()
>
> return _dec
>
> d
On Mon, 21 Nov 2011 14:44:34 +, Andrea Crotti wrote:
> With one colleague I discovered that the decorator code is always
> executed, every time I call a nested function:
"def" is a statement which is executed at runtime. Often people will talk
about "definition time" instead of "compile time
On 11/21/2011 05:11 PM, Dave Angel wrote:
You didn't mention what version of Python you're running. With Python
2, I got very different results. So I switched to Python 3.2, and I
still don't get exactly what you have.
A closure is needed if there's some non-global data outside the
functi
On 11/21/2011 10:35 AM, Andrea Crotti wrote:
On 11/21/2011 03:06 PM, Dave Angel wrote:
Your function 'nested' isn't nested, 'fun' is. What you discovered is
that a decorator is always executed, every time a nested decorated
function is defined.
You've also ust proved that it would be an incompa
On 11/21/2011 03:06 PM, Dave Angel wrote:
Your function 'nested' isn't nested, 'fun' is. What you discovered is
that a decorator is always executed, every time a nested decorated
function is defined.
You've also ust proved that it would be an incompatible change.
Doesn't that answer the que
On 11/21/2011 09:44 AM, Andrea Crotti wrote:
With one colleague I discovered that the decorator code is always
executed, every time I call
a nested function:
def dec(fn):
print("In decorator")
def _dec():
fn()
return _dec
def nested():
@dec
def fun():
print
Vedran wrote:
@plot_decorator(fig_params1)
def plt():
pylab.plot(..first graph data...)
pylab.plot(..second graph data..)
plt()
You could do something like
def call(f):
f()
@call
@plot_decorator(fig_params1)
def plt():
pylab.plot(..first graph data...)
Vedran wrote:
> Hello!
>
> Is it possible to apply a decorator on a block of code, without defining
> a function that decorator is applied to.
You can only decorate functions or classes.
> I have to generate a lot of similar graphs. For that reason I use
> plot_decorator to perform usual figur
On 7/2/10 11:58 AM, Alf P. Steinbach /Usenet wrote:
>
> #Py3
I'm stuck on Python 2.x, as I mentioned (albeit only in a comment). That
said this code does not seem to be including any Py3isms that aren't
compatible.
> class Thing(object):
> @expose()
> def test1(self, arg1):
> re
On 7/2/10 11:55 AM, Thomas Jollans wrote:
> Looks good! You may still want to use functools.update_wrapper or
> functools.wraps on "wrap".
Are you sure? I've been doing a little bit of experimentation and I only
did the 'wraps' on that inner function, because it seemed that it was
all that was nee
On Jul 2, 10:41 am, Stephen Hansen wrote:
> Okay, so!
>
> I actually never quite got around to learning to do deep and useful
> magic with decorators. I've only ever done the most basic things with
> them. Its all been a little fuzzy in my head: things like what order
> decorators end up being cal
* Stephen Hansen, on 02.07.2010 19:41:
Okay, so!
I actually never quite got around to learning to do deep and useful
magic with decorators. I've only ever done the most basic things with
them. Its all been a little fuzzy in my head: things like what order
decorators end up being called in if the
I like to think of decorators with arguments as decorator factory functions.
I try and unroll them as much as possible... I have some decorators that
work like so (and please note that the wraps and returns_as_output are
separate so that I can mutate the behavior as needed, if you just wanted a
si
On 07/02/2010 07:41 PM, Stephen Hansen wrote:
> Okay, so!
>
> I actually never quite got around to learning to do deep and useful
> magic with decorators. I've only ever done the most basic things with
> them. Its all been a little fuzzy in my head: things like what order
> decorators end up being
Steve Holden wrote:
MRAB wrote:
Steven D'Aprano wrote:
On Thu, 01 Apr 2010 00:27:51 +0100, MRAB wrote:
A decorator shouldn't call the function it's decorating.
*raises eyebrow*
Surely, in the general case, a decorator SHOULD call the function it is
decorating? I'm sure you know that, but yo
On Apr 1, 6:16 am, Steve Holden wrote:
> MRAB wrote:
>
> > I had the following idea: define the terms 'decorator', 'decoration' and
> > 'decoratee'. The decorator applies the decoration to the decoratee. The
> > decoratee is the function defined locally in the decorator.
>
> It would make more sen
MRAB wrote:
> Steven D'Aprano wrote:
>> On Thu, 01 Apr 2010 00:27:51 +0100, MRAB wrote:
>>
> A decorator shouldn't call the function it's decorating.
*raises eyebrow*
Surely, in the general case, a decorator SHOULD call the function it is
decorating? I'm sure you know that,
Steven D'Aprano wrote:
On Thu, 01 Apr 2010 00:27:51 +0100, MRAB wrote:
A decorator shouldn't call the function it's decorating.
*raises eyebrow*
Surely, in the general case, a decorator SHOULD call the function it is
decorating? I'm sure you know that, but your wording is funny and could
conf
On Thu, 01 Apr 2010 00:27:51 +0100, MRAB wrote:
>>> A decorator shouldn't call the function it's decorating.
>>
>> *raises eyebrow*
>>
>> Surely, in the general case, a decorator SHOULD call the function it is
>> decorating? I'm sure you know that, but your wording is funny and could
>> confuse
On Mar 31, 2:28 pm, Stephen Hansen wrote:
> On 2010-03-31 13:59:01 -0700, LX said:
>
>
>
>
>
> >> pass_decorator will be called when the decorated function is _defined_,
> >> but not when the decorated function is _called_.
>
> > Why is it then that during runtime, with a breakpoint in some
> > ar
Steven D'Aprano wrote:
On Wed, 31 Mar 2010 22:27:05 +0100, MRAB wrote:
LX wrote:
[...]
It looks to me the call stack still includes the additional level of
the decorator... what am I missing? Thank you for your time.
Are you still defining your decorators in the same way as in your
original
On Wed, 31 Mar 2010 22:27:05 +0100, MRAB wrote:
> LX wrote:
[...]
>> It looks to me the call stack still includes the additional level of
>> the decorator... what am I missing? Thank you for your time.
>
> Are you still defining your decorators in the same way as in your
> original post?
>
> A d
On 2010-03-31 13:59:01 -0700, LX said:
pass_decorator will be called when the decorated function is _defined_,
but not when the decorated function is _called_.
Why is it then that during runtime, with a breakpoint in some
arbitrary main() in main.py, I get something similar to the following
cal
LX wrote:
On Mar 30, 2:41 pm, MRAB wrote:
LX wrote:
On Mar 29, 6:34 pm, MRAB wrote:
LX wrote:
Hi all, I have a question about decorators. I would like to use them
for argument checking, and pre/post conditions. However, I don't want
the additional overhead when I run in non-debug mode. I co
On Mar 30, 2:41 pm, MRAB wrote:
> LX wrote:
> > On Mar 29, 6:34 pm, MRAB wrote:
> >> LX wrote:
> >>> Hi all, I have a question about decorators. I would like to use them
> >>> for argument checking, and pre/post conditions. However, I don't want
> >>> the additional overhead when I run in non-deb
LX wrote:
On Mar 29, 6:34 pm, MRAB wrote:
LX wrote:
Hi all, I have a question about decorators. I would like to use them
for argument checking, and pre/post conditions. However, I don't want
the additional overhead when I run in non-debug mode. I could do
something like this, using a simple tr
On Mar 29, 7:11 pm, Steven D'Aprano
wrote:
> On Mon, 29 Mar 2010 17:54:26 -0700, LX wrote:
> > Hi all, I have a question about decorators. I would like to use them for
> > argument checking, and pre/post conditions. However, I don't want the
> > additional overhead when I run in non-debug mode. I
On Mar 29, 6:34 pm, MRAB wrote:
> LX wrote:
> > Hi all, I have a question about decorators. I would like to use them
> > for argument checking, and pre/post conditions. However, I don't want
> > the additional overhead when I run in non-debug mode. I could do
> > something like this, using a simpl
On Mon, 29 Mar 2010 17:54:26 -0700, LX wrote:
> Hi all, I have a question about decorators. I would like to use them for
> argument checking, and pre/post conditions. However, I don't want the
> additional overhead when I run in non-debug mode. I could do something
> like this, using a simple trac
LX wrote:
Hi all, I have a question about decorators. I would like to use them
for argument checking, and pre/post conditions. However, I don't want
the additional overhead when I run in non-debug mode. I could do
something like this, using a simple trace example.
@decorator
def pass_decorator(
On Tue, Jul 14, 2009 at 5:44 PM, Ken Seehart wrote:
> Almost every time I use decorators, I find myself wishing I had access
> to the local namespace of the context from which the decorator is
> executed. In practice, decorator is being applied to a method, so the
> namespace in question would be
On Jul 14, 2:44 pm, Ken Seehart wrote:
[snip]
(e.g. there does not
> seem to be a good way to use multiple metaclasses in a class hierarchy,
> and more generally you can't stack them on top of each other (you can
> only have one metaclass per class)).
>
> Thoughts?
If "stacking" metaclasses (what
Ken Seehart schrieb:
Almost every time I use decorators, I find myself wishing I had access
to the local namespace of the context from which the decorator is
executed. In practice, decorator is being applied to a method, so the
namespace in question would be the dictionary of the class being cre
On Apr 6, 11:11 pm, "Diez B. Roggisch" wrote:
> Nose works via the func_name parameter of a method/function.
>
> So when you decorate it, you need to make sure that is set properly. One
> option is to do something like this:
>
> from functools import wraps
>
> def my_decorator(f):
> @wraps(f)
hyperboreean schrieb:
Hi, I am trying to test the business part of a web service. For this I
am using unittest & nose.
I wrote a decorator that should handle the xml test file retrieval, but
it seems I can't get it working with nose.
Here's the code:
* MyApp.py -- base test class *
import os
hyperboreean writes:
> From: hyperboreean
> Subject: decorators don't play nice with nose?
> Newsgroups: comp.lang.python
> To: python-list@python.org
> Date: Mon, 06 Apr 2009 11:01:04 +0300
>
> Hi, I am trying to test the business part of a web service. For this I
> am using unittest & nose.
>
Josiah Carlson wrote:
... I try to limit my use of decorators whenever possible, both because I
still have to support Python 2.3 (which doesn't support the syntax), and
because I find that they obfuscate what the code is doing more often
than not. I will admit that they are useful as a metapro
Johny wrote:
Hi,
Can anyone explain to me what are decorators for? What are advantages
of using them?
There are two questions: why wrap or modify a function after it is
modified? (others have answered this), and why the special syntax?
As to the second:
@deco
def f(): pass
is syntactic sug
In article ,
Johny wrote:
>
>Can anyone explain to me what are decorators for? What are advantages
>of using them?
Additional links that may be helpful:
http://wiki.python.org/moin/PythonDecoratorLibrary
http://mail.python.org/pipermail/baypiggies/2009-March/004448.html
http://mail.python.org/p
On Mar 6, 2:59 pm, Johny wrote:
> Hi,
> Can anyone explain to me what are decorators for? What are advantages
> of using them?
> Thanks
> L.
See http://pypi.python.org/pypi/decorator for many examples of useful
decorators, or the
references in the Wikipedia page:
http://en.wikipedia.org/wiki/Pyt
On Mar 6, 2009, at 9:13 AM, Michiel Overtoom wrote:
Johnny wrote...
Can anyone explain to me what are decorators for? What are advantages
of using them?
A tutorial article about decorators from Bruce Eckel:
http://www.artima.com/weblogs/viewpost.jsp?thread=240808
Thanks for that, Michiel
1 - 100 of 231 matches
Mail list logo