Mailman 3 May 2006 - Python-Dev

Python Benchmarks
by Niko Matsakis 14 Jun '06

14 Jun '06

Hello, After reading through recent Python mail regarding dictionaries and exceptions, I wondered, what is the current state of the art in Python benchmarks? I've tried before to find a definite set of Python benchmarks but failed. There doesn't seem to be an up to date reference, though if there is one and I didn't find it I would be very happy to be proven wrong. In any case, I would appreciate advice from the experts regarding what's available and what it tests. thank you, Niko Matsakis

16 74

how about adding ping's uuid module to the standard lib ?
by Fredrik Lundh 13 Jun '06

13 Jun '06

see subject and http://python.org/sf/1368955 comments ? </F> (note sure how my previous attempt to post this ended up on comp.lang.python instead, but I'll blame it on gmane... ;-)

12 40

zlib module doesn't build - inflateCopy() not found
by Guido van Rossum 09 Jun '06

09 Jun '06

I'm having trouble getting the zlib module to build (SVN HEAD). The error is: building 'zlib' extension gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/guido/projects/python/trunk/./Include -I../Include -I. -I/usr/local/include -I/home/guido/projects/python/trunk/Include -I/home/guido/projects/python/trunk/linux -c /home/guido/projects/python/trunk/Modules/zlibmodule.c -o build/temp.linux-i686-2.5/zlibmodule.o /home/guido/projects/python/trunk/Modules/zlibmodule.c: In function `PyZlib_uncopy': /home/guido/projects/python/trunk/Modules/zlibmodule.c:723: warning: implicit declaration of function `inflateCopy' gcc -pthread -shared build/temp.linux-i686-2.5/zlibmodule.o -L/usr/local/lib -lz -o build/lib.linux-i686-2.5/zlib.so *** WARNING: renaming "zlib" since importing it failed: build/lib.linux-i686-2.5/zlib.so: undefined symbol: inflateCopy It seems I have libz 1.1.4. Is this no longer supported? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

5 9

feature request: inspect.isgenerator
by Michele Simionato 06 Jun '06

06 Jun '06

Is there still time for new feature requests in Python 2.5? I am missing a isgenerator function in the inspect module. Right now I am using def isgenerator(func): return func.func_code.co_flags == 99 but it is rather ugly (horrible indeed). Michele Simionato

6 17

Let's stop eating exceptions in dict lookup
by Armin Rigo 05 Jun '06

05 Jun '06

Hi all, I've finally come around to writing a patch that stops dict lookup from eating all exceptions that occur during lookup, like rare bugs in user __eq__() methods. After another 2-hours long debugging session that turned out to be caused by that, I had a lot of motivation. http://python.org/sf/1497053 The patch doesn't change the PyDict_GetItem() interface, which is the historical core of the problem. It works around this issue by just moving the exception-eating bit there instead of in lookdict(), so it gets away with changing only dictobject.c (plus ceval.c's direct usage of ma_lookup for LOAD_GLOBAL). The benefit of this patch is that all other ways to work with dicts now correctly propagate exceptions, and this includes all the direct manipulation from Python code (including 'x=d[key]'). The reason I bring this up here is that I'm going to check it in 2.5, unless someone seriously objects. About the objection "we need a better fix, PyDict_GetItem() should really be fixed and all its usages changed": this would be good, and also require some careful compatibility considerations, and quite some work in total; it would also give a patch which is basically a superset of mine, so I don't think I'm going in the wrong direction there. A bientot, Armin

14 29

Request for patch review
by Georg Brandl 04 Jun '06

04 Jun '06

I've worked on two patches for NeedForSpeed, and would like someone familiar with the areas they touch to review them before I check them in, breaking all the buildbots which aren't broken yet ;) They are: http://python.org/sf/1346214 Better dead code elimination for the AST compiler http://python.org/sf/921466 Reduce number of open calls on startup GB Thanks! Georg

2 2

ssize_t question: longs in header files
by Neal Norwitz 04 Jun '06

04 Jun '06

$ grep long */*.h minus comments, etc yields several questions about whether some values should use Py_ssize_t rather than C longs. In particular: * hash values Include/abstract.h: long PyObject_Hash(PyObject *o); // also in object.h Include/object.h:typedef long (*hashfunc)(PyObject *); * ints: Include/intobject.h: long ob_ival; * thread values (probably no need to change since platform dependent) Attached is the whole list. This is just for C longs. The int list is much bigger and coming in a different msg. n

6 12

test_struct failure on 64 bit platforms
by Neal Norwitz 01 Jun '06

01 Jun '06

Bob, There are a couple of things I don't understand about the new struct. Below is a test that fails. $ ./python ./Lib/test/regrtest.py test_tarfile test_struct test_tarfile /home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l' format requires -2147483648 <= number <= 2147483647 return o.pack(*args) test_struct test test_struct failed -- pack('>l', -2147483649) did not raise error 1 test OK. 1 test failed: test_struct #### I fixed the error message (the min value was off by one before). I think I fixed a few ssize_t issues too. The remaining issues I know of are: * The warning only appears on 64-bit platforms. * The warning doesn't seem correct for 64-bit platforms (l is 8 bytes, not 4). * test_struct only fails if run after test_tarfile. * The msg from test_struct doesn't seem correct for 64-bit platforms. I tracked the problem down to trying to write the gzip tar file. Can you fix this? n

4 5

A can of worms... (does Python C code have a new C style?)
by Martin Blais 01 Jun '06

01 Jun '06

Hi all I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a "new" indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, "python" and "python-new", so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places. Is there a "grand plan" to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect? I could easily contribute to the vaccuuming here, by writing a script that will run emacs in batch mode on all the C code with the appropriate new style to do the following for each C file present: * re-indent the entire file according to the new guidelines * convert all the tabs to whitespace * delete trailing whitespace on all lines * remove those pesky CR if there are any * (anything else you'd like that's easily done from emacs?) The problem is that if someone was to check-in the result of this automation there would be a huge wave of complaints from merge conflicts for people who have a checkouts with lots of uncommitted changes. I don't see any painless way to do this. To ease the pain, however, it could be done at a fixed time, giving everyone a wide margin of chance to commit beforehand. In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply. I realize this is potentially opening a can of worms, but on the one hand I'd like to know what's the low-down on the indentation, and on the other hand I won't spend a second on this if this is only going to lead to trouble. Then again, maybe I misunderstood and the new rules apply only to Python 3k, in which case, well, press delete and move on. cheers,

6 6

Re: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
by Bob Ippolito 01 Jun '06

01 Jun '06

On May 26, 2006, at 4:56 PM, Guido van Rossum wrote: > On 5/26/06, martin.blais <python-checkins(a)python.org> wrote: >> Log: >> Support for buffer protocol for socket and struct. >> >> * Added socket.recv_buf() and socket.recvfrom_buf() methods, that >> use the buffer >> protocol (send and sendto already did). >> >> * Added struct.pack_to(), that is the corresponding buffer >> compatible method to >> unpack_from(). > > Hm... The file object has a similar method readinto(). Perhaps the > methods introduced here could follow that lead instead of using two > different new naming conventions? (speaking specifically about struct and not socket) pack_to and unpack_from are named as such because they work with objects that support the buffer API (not file-like-objects). I couldn't find any existing convention for objects that manipulate buffers in such a way. If there is an existing convention then I'd be happy to rename these. "readinto" seems to imply that some kind of position is being incremented. Grammatically it only works if it's implemented on all buffer objects, but in this case it's implemented on the Struct type. -bob

3 4