RetroSearch Browse

Sat Jun 3 18:48:45 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-June/065574.html

On 5/29/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Neal Norwitz]
> >  * hash values
> > Include/abstract.h:     long PyObject_Hash(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 Py_ssize_t 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-June/065574.html below:

[Python-Dev] ssize_t question: longs in header files