[Python-Dev] Py_ssize_t
Raymond Hettinger
raymond.hettinger at verizon.net
Tue Feb 20 10:47:01 CET 2007
After thinking more about Py_ssize_t, I'm surprised that we're not hearing about
64 bit users having a couple of major problems.
If I'm understanding what was done for dictionaries, the hash table can grow
larger than the range of hash values. Accordingly, I would expect large
dictionaries to have an unacceptably large number of collisions. OTOH, we
haven't heard a single complaint, so perhaps my understanding is off.
The other area where I expected to hear wailing and gnashing of teeth is users
compiling with third-party extensions that haven't been updated to a Py_ssize_t
API and still use longs. I would have expected some instability due to the size
mismatches in function signatures -- the difference would only show-up with
giant sized data structures -- the bigger they are, the harder they fall. OTOH,
there have not been any compliants either -- I would have expected someone to
submit a patch to pyport.h that allowed a #define to force Py_ssize_t back to a
long so that the poster could make a reliable build that included non-updated
third-party extensions.
In the absence of a bug report, it's hard to know whether there is a real
problem. Have all major third-party extensions adopted Py_ssize_t or is some
divine force helping unconverted extensions work with converted Python code?
Maybe the datasets just haven't gotten big enough yet.
Raymond
More information about the Python-Dev
mailing list