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
w
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 call
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
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 parameters (collection_snapsho
Paul
Thanks! I'm glad there is theory about my concern. I knew
I wasn't the only one with that question.
cs
> > https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
>
> Also:
>
> https://en.wikipedia.org/wiki/Expression_problem
--
https://mail.python.org/mailman/listinfo/python-lis
>
> a pattern like:
> if :
> elif :
>
>
Thanks. I really like this simple yet powerful suggestion you made. See
this...
import new_code
...
if foo:
new_code.do_new_stuff(..)
We can massively modify existing code by *ONLY* adding one import and a 2
line if snippet!!!
Very nice!
cs
-
If you want to know, I'm trying to add metaprogramming (macros!) to a tiny Lisp
interpreter I wrote. I'm hesitant to mess with all that nice debugged code to
add this new stuff.
--
https://mail.python.org/mailman/listinfo/python-list
I have some code I'd like to extend without modifying it.
I'm sure this is a common pattern. I wondered what the
options were for "extending without modifying (much)".
I'm aware one can import a module and add functions to decorators.
Are there other ways?
Steve D'Aprano :
> When you run Javascript in your browser, you allow anonymous,
> untrusted third-parties to run code on your PC.
Yes. I'm running NoScript on my browser, but I believe JavaScript (or
equivalent) is the way forward. I *love* my Turing Tarpit.
Aus dem Paradies, das [Turing] un
On 06/28/17 17:59, Steve D'Aprano wrote:
On Thu, 29 Jun 2017 01:56 am, Peter Pearson wrote:
(Blushing) Thanks. Life is getting difficult for us JavaScript paranoids.
Its not paranoia if they're really out to get you.
https://www.cnet.com/news/javascript-opens-doors-to-browser-based-attacks/
On Thu, 29 Jun 2017 01:56 am, Peter Pearson wrote:
> (Blushing) Thanks. Life is getting difficult for us JavaScript paranoids.
Its not paranoia if they're really out to get you.
https://www.cnet.com/news/javascript-opens-doors-to-browser-based-attacks/
https://www.proofpoint.com/us/corporate-b
On Tue, 27 Jun 2017 16:43:38 +, Andre Müller wrote:
> Peter Pearson schrieb am Di., 27. Juni 2017 um
> 18:35 Uhr:
>
>> On Tue, 27 Jun 2017 15:10:53 + (UTC), Saurabh Chaturvedi wrote:
>> > https://opensource.google.com/projects/py-decorators-tutorial
>>
>&g
ler wrote:
> Activate JavaScript, then you can see the content.
> I had the same problem.
>
> Peter Pearson schrieb am Di., 27. Juni 2017 um
> 18:35 Uhr:
>
> > On Tue, 27 Jun 2017 15:10:53 + (UTC), Saurabh Chaturvedi wrote:
> > > https://opensource.google.com/
Activate JavaScript, then you can see the content.
I had the same problem.
Peter Pearson schrieb am Di., 27. Juni 2017 um
18:35 Uhr:
> On Tue, 27 Jun 2017 15:10:53 + (UTC), Saurabh Chaturvedi wrote:
> > https://opensource.google.com/projects/py-decorators-tutorial
>
> &q
On Tue, 27 Jun 2017 15:10:53 + (UTC), Saurabh Chaturvedi wrote:
> https://opensource.google.com/projects/py-decorators-tutorial
"No Results found."
--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list
https://opensource.google.com/projects/py-decorators-tutorial
--
https://mail.python.org/mailman/listinfo/python-list
andrew.hol...@otternetworks.de wrote:
> Hi,
>
> I'm trying to work out how to pass parameters through decorators:
>
> class Meow():
>
> def __init__(self, arg1, arg2):
> print("INIT ClassBasedDecoratorWithParams")
> print(arg1)
&
On 2017-04-12 21:42, andrew.hol...@otternetworks.de wrote:
Hi,
I'm trying to work out how to pass parameters through decorators:
class Meow():
def __init__(self, arg1, arg2):
print("INIT ClassBasedDecoratorWithParams")
print(arg1)
print(arg2)
Hi,
I'm trying to work out how to pass parameters through decorators:
class Meow():
def __init__(self, arg1, arg2):
print("INIT ClassBasedDecoratorWithParams")
print(arg1)
print(arg2)
def makebold(self, fn):
def wrapped():
On Fri, Apr 1, 2016 at 11:14 AM, Matthias welp wrote:
>> An example of the transformation would help here
>
> An example, that detects cycles in a graph, and doesn't do an update if
> the graph has cycles.
Thanks.
> class A(object):
> def __init__(self, parent):
> @prevent_cycles
>
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
I have the following code to run a shell command and kill it if it
does not return within a certain amount of time:
def run_with_time_limit(command, limit):
"""Run the given command via a shell.
Kill the command, and raise an exception, if the
execution time exceeds seconds.
Else
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 wr
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,
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
d take top-posting if I were enlightened about how decorators could be
valuable. Sadly, I didn't see it instantly, or even afterwards.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
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 decorato
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 &qu
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 rea
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 decorat
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,"
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 chan
On Mon, 21 Jul 2014 00:30:00 -0700, CHIN Dihedral wrote:
> Uhn, a local object inside a function can be passed back in Python.
>
> Of course, a local function is treated as an object in Python,and the GC
> is built-in.
Sigh, the Dihedral bot is not what it used to be...
--
Steven
--
https://
On Saturday, July 19, 2014 8:44:25 PM UTC+8, Wojciech Giel wrote:
> On 19/07/14 12:40, Jerry lu wrote:
>
> > oh yeah i forgot about the decorators. Um say that you wanted to decorate a
> > function with the outer() func you would just put @outer on top of it? And
> > thi
On Sat, 19 Jul 2014 03:52:18 -0700, Jerry lu wrote:
> Ok so i am trying to learn this and i do not understand some of it. I
> also tried to searched the web but i couldnt find any answers.
>
> 1. I dont understand when i will need to use a function that returns
> another function. eg
>
Ok thanks so much i really want to get good. I also found this MIT open course
lectures for python. Is this good to use as a source of learning? I think it
would because it is MIT.
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Jul 20, 2014 at 12:24 PM, Jerry lu wrote:
> ok I seem to very confused about this. Is there like a page or web page that
> like completely sums this up so i can study. I am going to look up 'functions
> in python'.
Yep, look up stuff like that. I gave you some keywords to search for
(we
. I am all good with decorators just I
can't wrap my head around why we need a function within a function? like the
outer and inner thing. for example if we have like:
>>> def multi_squared(func):
def multi():
return (func)**2
return ma
On 19/07/14 12:40, Jerry lu wrote:
oh yeah i forgot about the decorators. Um say that you wanted to decorate a
function with the outer() func you would just put @outer on top of it? And this
is the same as passing another func into the outer func?
yes.
syntax was added because with very long
On 19/07/14 11:52, Jerry lu wrote:
Ok so i am trying to learn this and i do not understand some of it. I also
tried to searched the web but i couldnt find any answers.
1. I dont understand when i will need to use a function that returns another
function.
eg
def outer():
On 19/07/14 11:52, Jerry lu wrote:
Ok so i am trying to learn this and i do not understand some of it. I also
tried to searched the web but i couldnt find any answers.
1. I dont understand when i will need to use a function that returns another
function.
eg
def outer():
Ok thanks man I have never used forums and stuff before but it is great help
thank you so much.
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, Jul 19, 2014 at 9:40 PM, Jerry lu wrote:
> oh yeah i forgot about the decorators. Um say that you wanted to decorate a
> function with the outer() func you would just put @outer on top of it? And
> this is the same as passing another func into the outer func?
>
> and also
oh yeah i forgot about the decorators. Um say that you wanted to decorate a
function with the outer() func you would just put @outer on top of it? And this
is the same as passing another func into the outer func?
and also with the first example you say x is in the scope when is was created
a function 'func'. You can if you like, but it'll work the same
regardless. There is no magic happening here.
None of this has anything to do with decorators, though.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Ok so i am trying to learn this and i do not understand some of it. I also
tried to searched the web but i couldnt find any answers.
1. I dont understand when i will need to use a function that returns another
function.
eg
def outer():
def inner():
Tim Chase wrote:
I'd have figured they would be associative, making the result end up
the same either way, but apparently not.
They're not associative because function application
is not associative: f(g(x)) is not the same thing as
f(g)(x).
--
Greg
--
https://mail.python.org/mailman/listinfo/
On 2013-10-29 17:42, MRAB wrote:
> If you apply the stacked decorators you get:
>
> myfun = dec1(args1)(dec2(args2)(dec3(args3)(myfun)))
>
> If you apply dec_all you get:
>
> myfun = dec1(args1)(dec2(args2)(dec3(args3)))(myfun)
>
> See the difference? You
Tim Chase wrote:
> I've got some decorators that work fine as such:
>
> @dec1(args1)
> @dec2(args2)
> @dec3(args3)
> def myfun(...):
> pass
>
> However, I used that sequence quite a bit, so I figured I could do
> something like
>
> dec
On 29/10/2013 16:54, Tim Chase wrote:
I've got some decorators that work fine as such:
@dec1(args1)
@dec2(args2)
@dec3(args3)
def myfun(...):
pass
However, I used that sequence quite a bit, so I figured I could do
something like
dec_all = dec1(args1)(dec2(args2)(dec3(
I've got some decorators that work fine as such:
@dec1(args1)
@dec2(args2)
@dec3(args3)
def myfun(...):
pass
However, I used that sequence quite a bit, so I figured I could do
something like
dec_all = dec1(args1)(dec2(args2)(dec3(args3)))
to consolidate the whole mess do
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.
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.set_trace()
req = method_self.__
On 11Oct2013 02:37, Gilles Lenfant wrote:
> * Adding an "__original__" attribute to the wrapper func in the decorators of
> my own
Just one remark: Call this __original or _original (or even original).
The __x__ names are reserved for python operations (like __add__, supportin
that matters is how they
behave with the decorators.
If the undecorated function is buggy, the decorated function will
be buggy. But the bug will be harder to resolve, and if you're
especially lucky the decorator will often-but-not-always conceal
the bug in the inner function.
Wanting to te
your own stuff so you should have control of
your own decorators (okay, you may have to adapt a few others ;) .
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
hey
behave with the decorators.
In article ,
Cameron Simpson wrote:
If the undecorated function is buggy, the decorated function will
be buggy. But the bug will be harder to resolve, and if you're
especially lucky the decorator will often-but-not-always conceal
the bug in the inner functi
Cameron, Steven, Ben, Ned, Terry, Roy. Many thanks for this interesting
discussion.
I ended up... mixing some solutions provided by your hints :
* Adding an "__original__" attribute to the wrapper func in the decorators of
my own
* Playing with "func_closure" to test functi
ss with a .__call__
method and attach the original function to instances as an attribute.
(Indeed, decorators were borrowed from class-happy Java ;-). But there
is no standard as to what the function attribute of instances is called.
The OP's request for accessing the function without modif
On 10/11/2013 4:17 AM, Terry Reedy wrote:
On 10/10/2013 11:13 PM, Cameron Simpson wrote:
On 11Oct2013 02:55, Steven D'Aprano
wrote:
def undecorate(f):
"""Return the undecorated inner function from function f."""
return f.func_closure[0].cell_contents
Whereas this feels like black
inner._unwrapped = func # make it public if you prefer
return inner
which makes it all nice and clean and above board. (I seem to recall a
proposal to have functools.wraps do this automatically...)
The explicit attribute can also be set by class rather than closure
based decorators.
--
On 10/10/2013 11:13 PM, Cameron Simpson wrote:
On 11Oct2013 02:55, Steven D'Aprano
wrote:
def undecorate(f):
"""Return the undecorated inner function from function f."""
return f.func_closure[0].cell_contents
Whereas this feels like black magic. Is this portable to any decorated
On 11Oct2013 05:51, Steven D'Aprano
wrote:
> On Fri, 11 Oct 2013 15:36:29 +1100, Cameron Simpson wrote:
> > But is it reliable? Will it work on any decorated function?
>
> *Any* decorated function? No, of course not, since decorators can do
> anything they like: [...
On Fri, 11 Oct 2013 15:36:29 +1100, Cameron Simpson wrote:
> But is it reliable? Will it work on any decorated function?
*Any* decorated function? No, of course not, since decorators can do
anything they like:
def decorate(func):
return lambda *args: "Surprise!"
On Fri, 11 Oct 2013 14:13:19 +1100, Cameron Simpson wrote:
> On 11Oct2013 02:55, Steven D'Aprano
> wrote:
>> On Fri, 11 Oct 2013 09:12:38 +1100, Cameron Simpson wrote:
>> > Speaking for myself, I would be include to recast this code:
>> >
>> > @absolutize
>> > def addition(a, b):
>> >
On 11Oct2013 14:42, Ben Finney wrote:
> Cameron Simpson writes:
> > On 11Oct2013 02:55, Steven D'Aprano
> > wrote:
> > > def undecorate(f):
> > > """Return the undecorated inner function from function f."""
> > > return f.func_closure[0].cell_contents
> >
> > Whereas this feels like bla
Cameron Simpson writes:
> On 11Oct2013 02:55, Steven D'Aprano
> wrote:
> > def undecorate(f):
> > """Return the undecorated inner function from function f."""
> > return f.func_closure[0].cell_contents
>
> Whereas this feels like black magic. Is this portable to any decorated
> function
On 11Oct2013 02:55, Steven D'Aprano
wrote:
> On Fri, 11 Oct 2013 09:12:38 +1100, Cameron Simpson wrote:
> > Speaking for myself, I would be include to recast this code:
> >
> > @absolutize
> > def addition(a, b):
> > return a + b
> >
> > into:
> >
> > def _addition(a, b):
> >
On 10Oct2013 19:44, Ned Batchelder wrote:
> > I have to admit I'm having a hard time understanding why you'd need
> > to test the undecorated functions. After all, the undecorated
> > functions aren't available to anyone. All that matters is how they
> >
On Fri, 11 Oct 2013 09:12:38 +1100, Cameron Simpson wrote:
> On 10Oct2013 07:00, Gilles Lenfant wrote:
>> (explaining the title) : my app has functions and methods (and maybe
>> classes in the future) that are decorated by decorators provided by the
>> standard library
decorated functions. After all, the undecorated
> functions aren't available to anyone. All that matters is how they
> behave with the decorators.
If the undecorated function is buggy, the decorated function will
be buggy. But the bug will be harder to resolve, and if you're
On 10/10/2013 10:00 AM, Gilles Lenfant wrote:
To add to the other two responses so far...
(explaining the title) : my app has functions and methods (and maybe classes in
the future) that are decorated by decorators provided by the standard library
or 3rd party packages.
But I need to test
On 10/10/13 6:12 PM, Cameron Simpson wrote:
On 10Oct2013 07:00, Gilles Lenfant wrote:
(explaining the title) : my app has functions and methods (and
maybe classes in the future) that are decorated by decorators
provided by the standard library or 3rd party packages.
But I need to test
On 10Oct2013 07:00, Gilles Lenfant wrote:
> (explaining the title) : my app has functions and methods (and
> maybe classes in the future) that are decorated by decorators
> provided by the standard library or 3rd party packages.
>
> But I need to test "undecorated" fu
Hi,
(explaining the title) : my app has functions and methods (and maybe classes in
the future) that are decorated by decorators provided by the standard library
or 3rd party packages.
But I need to test "undecorated" functions and methods in my unit tests,
preferably without addin
Dave Angel wrote:
> The decorator function will execute while *compiling* the class A, and
> the one in class B is unreferenced.
No, the decorator function is called when *executing* the class body of A.
Compilation could have happened weeks earlier.
It really does make it a lot easier to und
Jason Swails於 2013年1月31日星期四UTC+8上午8時34分03秒寫道：
> Hello,
>
>
> I was having some trouble understanding decorators and inheritance and all
> that. This is what I was trying to do:
>
>
>
> # untested
> class A(object):
> def _protector_decorator(fcn):
arsed
through (in my app, if you're going to spend the time to parse through the
whole RemotePatch, it just gets downloaded and instantiated as a Patch).
So this last form of inheritance made the most sense to me.
>
>
> > However, my desire to use decorators was not to disable methods i
ot used, consider a flatter
hierarchy:
class Patch: ...
class RemotePatch(Patch): ...
rather than:
class PatchBase: ...
class Patch(PatchBase): ...
class RemotePatch(Patch): ...
although this is okay:
class PatchBase: ...
class Patch(PatchBase): ...
class Rem
Steven D'Aprano wrote:
>> def _protector_decorator(fcn):
>> def newfcn(self, *args, **kwargs):
>> return fcn(self, *args, **kwargs)
>> return newfcn
>
> Well, that surely isn't going to work, because it always decorates the
> same function, the global "fcn".
Good grief, I can't b
s and AuthorClass are related (via
> inheritance), the RemoteAuthorClass has the potential for HTTPError's now.
> I could just expand the A class decorator to catch the HTTPError, but
> since that should not be possible in AuthorClass, I'd rather not risk
> masking a bug. I
On Thu, Jan 31, 2013 at 10:28 AM, Chris Angelico wrote:
>
> >> Well, that surely isn't going to work, because it always decorates the
> >> same function, the global "fcn".
> >
> >
> > I don't think this is right. fcn is a passed function (at least if it
> acts
> > as a decorator) that is declare
On Fri, Feb 1, 2013 at 12:25 AM, Jason Swails wrote:
> On Thu, Jan 31, 2013 at 12:46 AM, Steven D'Aprano
> wrote:
>>
>> On Wed, 30 Jan 2013 19:34:03 -0500, Jason Swails wrote:
>>
>> > Hello,
>> >
>> > I was having some trouble understandin
On Thu, Jan 31, 2013 at 12:46 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 30 Jan 2013 19:34:03 -0500, Jason Swails wrote:
>
> > Hello,
> >
> > I was having some trouble understanding decorators and inheritance and
> > a
On Wed, 30 Jan 2013 19:34:03 -0500, Jason Swails wrote:
> Hello,
>
> I was having some trouble understanding decorators and inheritance and
> all that. This is what I was trying to do:
>
> # untested
> class A(object):
>def _protector_decorator(fcn):
>
On 01/30/2013 07:34 PM, Jason Swails wrote:
Hello,
I was having some trouble understanding decorators and inheritance and all
that. This is what I was trying to do:
# untested
class A(object):
def _protector_decorator(fcn):
def newfcn(self, *args, **kwargs):
return fcn
Hello,
I was having some trouble understanding decorators and inheritance and all
that. This is what I was trying to do:
# untested
class A(object):
def _protector_decorator(fcn):
def newfcn(self, *args, **kwargs):
return fcn(self, *args, **kwargs)
return newfcn
- 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
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
1 - 100 of 666 matches
Mail list logo
