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.
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
/home/guido/projects/python/trunk/Modules/zlibmodule.c: In function
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/)
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
return func.func_code.co_flags == 99
but it is rather ugly (horrible indeed).
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.
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
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.
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 ;)
Better dead code elimination for the AST compiler
Reduce number of open calls on startup GB
$ 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.
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
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 <= number <= 2147483647
test test_struct failed -- pack('>l', -2147483649) did not raise error
1 test OK.
1 test failed:
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?
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
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.
On May 26, 2006, at 4:56 PM, Guido van Rossum wrote:
> On 5/26/06, martin.blais <python-checkins(a)python.org> wrote:
>> 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
> 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
Grammatically it only works if it's implemented on all buffer
in this case it's implemented on the Struct type.