[Python-Dev] ssize_t question: longs in header files (original) (raw)
Neal Norwitz nnorwitz at gmail.com
Sat Jun 3 18:48:45 CEST 2006
- Previous message: [Python-Dev] Python Benchmarks
- Next message: [Python-Dev] Unhashable objects and __contains__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 5/29/06, Tim Peters <tim.peters at gmail.com> wrote:
[Neal Norwitz] > * hash values > Include/abstract.h: long PyObjectHash(PyObject *o); // also in object.h > Include/object.h:typedef long (*hashfunc)(PyObject *);
We should leave these alone for now. There's no real connection between the width of a hash value and the number of elements in a container, and Pyssizet is conceptually only related to the latter.
True. Though it might be easier to have one big type changing than two. If this is likely to change in the future (and I think it should to avoid hash collisions and provide better consistency on 64-bit archs), would it be good to add:
typedef long Py_hash_t;
This will not change the type, but will make it easy to change in the future. I'm uncertain about doing this in 2.5. I think it would help me port code, but I'm only familiar with the Python base, not wild and crazy third party C extensions.
The reason why it's easier for me is that grep can help me find and fix just about everything. There are fewer exceptions (longs left). It would also help mostly from a doc standpoint to have typedefs for Py_visit_t and other ints as well. But this also seems like diminishing returns.
n
- Previous message: [Python-Dev] Python Benchmarks
- Next message: [Python-Dev] Unhashable objects and __contains__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]