Python-Dev September 2006

python-dev@python.org

100 participants
121 discussions

Exceptions and slicing
by Thomas Heller 12 Oct '06

12 Oct '06

Is it an oversight that exception instances do no longer support slicing in Python 2.5? This code works in 2.4, but no longer in 2.5: try: open("", "r") except IOError, details: print details[:] Thomas

3 6

Signals, threads, blocking C functions
by Gustavo Carneiro 12 Oct '06

12 Oct '06

We have to resort to timeouts in pygtk in order to catch unix signals in threaded mode. The reason is this. We call gtk_main() (mainloop function) which blocks forever. Suppose there are threads in the program; then any thread can receive a signal (e.g. SIGINT). Python catches the signal, but doesn't do anything; it simply sets a flag in a global structure and calls Py_AddPendingCall(), and I guess it expects someone to call Py_MakePendingCalls(). However, the main thread is blocked calling a C function and has no way of being notified it needs to give control back to python to handle the signal. Hence, we use a 100ms timeout for polling. Unfortunately, timeouts needlessly consume CPU time and drain laptop batteries. According to [1], all python needs to do to avoid this problem is block all signals in all but the main thread; then we can guarantee signal handlers are always called from the main thread, and pygtk doesn't need a timeout. Another alternative would be to add a new API like Py_AddPendingCallNotification, which would let python notify extensions that new pending calls exist and need to be processed. But I would really prefer the first alternative, as it could be fixed within python 2.5; no need to wait for 2.6. Please, let's make Python ready for the enterprise! [2] [1] https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c3 [2] http://perkypants.org/blog/2006/09/02/rfte-python/

6 11

Python Doc problems
by xah lee 08 Oct '06

08 Oct '06

There are a lot reports on the lousy state of python docs. I'm not much in the python community so i don't know what the developers are doing anything about it. anyway, i've rewrote the Python's RE module documentation, at: http://xahlee.org/perl-python/python_re-write/lib/module-re.html and have recently made the term of user clear. may i ask what the python developers is doing about the python's docs? Are you guys aware, that there are rampant criticisms of python docs and many diverse tries by various individuals to rewrite the doc by starting another wiki or site? Xah xah(a)xahlee.org ∑ http://xahlee.org/ ☄

16 19

PEP 351 - do while
by Hans Polak 04 Oct '06

04 Oct '06

Hi, Just an opinion, but many uses of the 'while true loop' are instances of a 'do loop'. I appreciate the language layout question, so I'll give you an alternative: do: <body> <setup code> while <condition> Cheers, Hans Polak. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

9 20

Caching float(0.0)
by Nick Craig-Wood 02 Oct '06

02 Oct '06

I just discovered that in a program of mine it was wasting 7MB out of 200MB by storing multiple copies of 0.0. I found this a bit suprising since I'm used to small ints and strings being cached. I added the apparently nonsensical lines + if age == 0.0: + age = 0.0 # return a common object for the common case and got 7MB of memory back! Eg :- Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=0.0 >>> print id(a), id(0.0) 134738828 134738844 >>> Is there any reason why float() shouldn't cache the value of 0.0 since it is by far and away the most common value? A full cache of floats probably doesn't make much sense though since there are so many 'more' of them than integers and defining small isn't obvious. -- Nick Craig-Wood <nick(a)craig-wood.com> -- http://www.craig-wood.com/nick

11 13

Re: [Python-Dev] Caching float(0.0)
by Kristján V. Jónsson 02 Oct '06

02 Oct '06

Well, a lot of extension code, like ours use PyFloat_FromDouble(foo); This can be from vectors and stuff. Very often these are values from a database. Integral float values are very common in such case and id didn't occur to me that they weren't being reused, at least for small values. Also, a lot of arithmetic involving floats is expected to end in integers, like computing some index from a float value. Integers get promoted to floats when touched by them, as you know. Anyway, I now precreate integral values from -10 to 10 with great effect. The cost is minimal, the benefit great. Cheers, Kristján -----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com(a)python.org [mailto:python-dev-bounces+kristjan=ccpgames.com@python.org] On Behalf Of "Martin v. Löwis" Sent: 30. september 2006 08:48 To: Bob Ippolito Cc: python-dev(a)python.org Subject: Re: [Python-Dev] Caching float(0.0) Bob Ippolito schrieb: > My guess is that people do have this problem, they just don't know > where that memory has gone. I know I don't count objects unless I have > a process that's leaking memory or it grows so big that I notice (by > swapping or chance). Right. Although I do wonder what kind of software people write to run into this problem. As Guido points out, the numbers must be the result from some computation, or created by an extension module by different means. If people have many *simultaneous* copies of 0.0, I would expect there is something else really wrong with the data structures or algorithms they use. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com

2 1

Re: [Python-Dev] Caching float(0.0)
by Nick Maclaren 02 Oct '06

02 Oct '06

"Jason Orendorff" <jason.orendorff(a)gmail.com> wrote: > > Anyway, this kind of static analysis is probably more entertaining > than relevant. ... Well, yes. One can tell that by the piffling little counts being bandied about! More seriously, yes, it is Well Known that 0.0 is the Most Common Floating-Point Number is most numerical codes; a lot of older (and perhaps modern) sparse matrix algorithms use that to save space. In the software floating-point that I have started to draft some example code but have had to shelve (no, I haven't forgotten) the values I predefine are Invalid, Missing, True Zero and Approximate Zero. The infinities and infinitesimals (a.k.a. signed zeroes) could also be included, but are less common and more complicated. And so could common integers and fractions. It is generally NOT worth doing a cache lookup for genuinely numerical code, as the common cases that are not the above rarely account for enough of the numbers to be worth it. I did a fair amount of investigation looking for compressibility at one time, and that conclusion jumped out at me. The exact best choice depends entirely on what you are doing. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

5 5

difficulty of implementing phase 2 of PEP 302 in Python source
by Brett Cannon 01 Oct '06

01 Oct '06

I am at the point with my security work that I need to consider how I am going to restrict importing modules. My current plan is to basically implement phase 2 of PEP 302 and control imports through what importer objects are provided. This work should lead to a meta_path importer for built-ins and then path_hooks importers for .py, .pyc, and extension modules. But it has been suggested here that the import machinery be rewritten in Python. Now I have never touched the import code since it has always had the reputation of being less than friendly to work with. I am asking for opinions from people who have worked with the import machinery before if it is so bad that it is worth trying to re-implement the import semantics in pure Python or if in the name of time to just work with the C code. Basically I will end up breaking up built-in, .py, .pyc, and extension modules into individual importers and then have a chaining class to act as a combined .pyc/.py combination importer (this will also make writing out to .pyc files an optional step of the .py import). Any opinions would be greatly appreciated on this. I need to get back to my supervisor by the end of the day Friday with a decision as to whether I think it is worth the rewrite. If you are interested in helping with the Python rewrite (or in general if the work is done with the C code), please let me know since if enough people want to help with the Python rewrite it might help wash out the extra time needed to make it work. -Brett

2 1

Tix not included in 2.5 for Windows
by Christos Georgiou 01 Oct '06

01 Oct '06

Does anyone know why this happens? I can't find any information pointing to this being deliberate. I just upgraded to 2.5 on Windows (after making sure I can build extensions with the freeware VC++ Toolkit 2003) and some of my programs stopped operating. I saw in a French forum that someone else had the same problem, and what they did was to copy the relevant files from a 2.4.3 installation. I did the same, and it seems it works, with only a console message appearing as soon as a root window is created: attempt to provide package Tix 8.1 failed: package Tix 8.1.8.4 provided instead Cheers.

5 7

Possible semantic changes for PEP 352 in 2.6
by Brett Cannon 30 Sep '06

30 Sep '06

I am working on PEP 352 stuff for 2.6 and there are two changes that I think should be made that are not explicitly laid out in the PEP. First, and most dramatic, involves what is legal to list in an 'except' clause. Right now you can listing *anything*. This means ``except 42`` is totally legal even though raising a number is not. Since I am deprecating catching string exceptions, I can go ahead and deprecate catching *any* object that is not a legitimate object to be raised. The second thing is changing PyErr_GivenExceptionMatches() to return 0 on false, 1 on true, and -1 on error. As of right now there is no defined error return value. While it could be suggested to check PyErr_Occurred() after every call, there is a way to have the return value reflect all possible so I think this changed should be made. Anybody have objections with any of the changes I am proposing? -Brett

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev September 2006