atexit.register does not return the registered function. IMHO, it should.
Hi all! Since that the decorator syntax is upon us, I think it would be good if atexit.register() was returning the function passed as argument. This simple change to the library would solve a problem with the use of atexit.register as a decorator (and I can't think of any use case where this change would break any code). I describe the problem in the following text. Problem using atexit.register as a decorator In his April 2005 article titled `Python 2.4 Decorators: Reducing code duplication and consolidating knowledge`_ , Phillip Eby describes how you can use `atexit.register()`_ from the standard Python library. He shows how to use the decorator syntax to register a function that will execute at program termination. Here is how it goes:: @atexit.register def goodbye(): print "Goodbye, terminating..." However, there is one fundamental problem with this: atexit.register() returns None. Since the above code corresponds to:: def goodbye(): print "Goodbye, terminating..." goodbye = atexit.register(goodbye) the code registers goodbye but right after it binds goodbye to None! You can see this in the following session:: >>> import atexit >>> @atexit.register ... def goodbye(): ... print "Goodbye, terminating..." ... >>> goodbye() Traceback (most recent call last): File "", line 1, in ? TypeError: 'NoneType' object is not callable >>> >>> goodbye >>> type(goodbye) >>> There is two solutions to this problem: 1. Use another function to register and decorate. 2. Change atexit.register() in the Python library so that it returns the function it registers. Solution 1 can be implemented right away:: def atexit_register(fct): atexit.register(fct) return fct @atexit_register def goodbye2(): print "Goodbye 2!!" and it works: it registers the function for execution at termination but leaves goodbye2 callable:: >>> def atexit_register(fct): ... atexit.register(fct) ... return fct ... >>> @atexit_register ... def goodbye2(): ... print "Goodbye 2!!" ... >>> goodbye2() Goodbye 2!! >>> goodbye2 >>> .. References .. _atexit.register(): http://www.python.org/doc/current/lib/module-atexit.html .. _Python 2.4 Decorators\: Reducing code duplication and consolidating knowledge: http://www.ddj.com/184406073 -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit.register does not return the registered function. IMHO, it should.
On Nov 16, 11:38 am, Carsten Haese <[EMAIL PROTECTED]> wrote: > On Thu, 2006-11-16 at 08:03 -0800, [EMAIL PROTECTED] wrote: > > @atexit.register > > def goodbye(): > > print "Goodbye, terminating..." > > > However, there is one fundamental problem with this: atexit.register() > > returns None. Since the above code corresponds to:: > > > def goodbye(): > > print "Goodbye, terminating..." > > goodbye = atexit.register(goodbye) > > > the code registers goodbye but right after it binds goodbye to None!While > > it wouldn't hurt to have atexit.register return the function it > registered, this "problem" is only a problem if you wish to call the > function manually, since atexit already registered the reference to the > intended function before your reference to it gets rebound to None. > Normally one would register a function with atexit precisely because > they don't want to call it manually. > There are *two* problems. 1 - As you said, most of the time you would not call the function explicitly, but in some situation you might want to. 2- If you want to document your code using introspection, or use an IDE to look at the function, if the function disappeared from sight, you won't be able to. The second problem is similar to what happens when a decorator changes the signature of a function. -- P.R. -- http://mail.python.org/mailman/listinfo/python-list
Surprise with special floating point values
Hi all, While trying to use simplejson under Python 2.4.3 I have been investigating the handling of special floating point values and found that both Python 2.4 and 2.5 return False when comparing a NaN with itself. Although surprising, I imagine it could also be correct since NaN is not a number. But is it correct? Notice the result of comparing c with itself in the following Python 2.5 session (it works the same on Python 2.4.3) under Win32:: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a = 1e300 * 1e300 >>> a 1.#INF >>> b = 1e6 >>> b 1.#INF >>> a == b True >>> c = a - a >>> c -1.#IND >>> d = b - b >>> d -1.#IND >>> c == d False >>> c == c False >>> b == b True >>> a == a True >>> a is a True >>> b is b True >>> c is c True >>> d is d True >>> Thanks, -- Pierre Rouleau -- http://mail.python.org/mailman/listinfo/python-list
Re: Surprise with special floating point values
On Nov 29, 12:53 pm, [EMAIL PROTECTED] wrote: > Hi all, > > While trying to use simplejson under Python 2.4.3 I have been > investigating the handling of special floating point values and found > that both Python 2.4 and 2.5 return False when comparing a NaN with > itself. Although surprising, I imagine it could also be correct since > NaN is not a number. But is it correct? And of course it is correct... As NaN does not compare with itself in floating point: http://en.wikipedia.org/wiki/NaN Should have read it earlier... > -- > Pierre Rouleau -- http://mail.python.org/mailman/listinfo/python-list
Re: Surprise with special floating point values
On Nov 29, 1:11 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > While trying to use simplejson under Python 2.4.3 I have been > > investigating the handling of special floating point valuesnote that JSON > > doesn't support non-numeric floating point values, as can > be seen by the "number" syntax description on this page: > > http://www.json.org/ > > (and as I pointed out in another thread on this topic, Python relies on > the C library for serialization of floats, so non-numeric floating point > values aren't portable between Python versions either). > > That's true, but I ran into a problem with simplejson under Python 2.4.3 on Win32, where it fails to serialize 1.0 properly (and I reported the problem to its author, and the fact that it works fine under Python 2.5). There is another thread (Inconsistency producing constant for float "infinity") that talks about differences between Python 2.5 and earlier versions regarding treatment of non-numeric floating point values. So, while investigating the simplejson problem, I though I had found a problem with the handling of NaN (which obviously is not the case). - Pierre R. -- http://mail.python.org/mailman/listinfo/python-list
