On 5/29/06, Tim Peters <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
