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

2006-06-03 Thread Neal Norwitz
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 connectio

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

2006-05-29 Thread Thomas Wouters
On 5/29/06, "Martin v. Löwis" < [EMAIL PROTECTED]> wrote: I agree using Py_ssize_t would be a "smaller" change, and one thatlikely has less performance impact. It would still be a large change,and should be only done if we know for sure we don't want it to be a 64-bit type always the next day.Well

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

2006-05-29 Thread Martin v. Löwis
Thomas Wouters wrote: > Neal Norwitz wrote: > > minus comments, etc yields several questions about whether some > > values should use Py_ssize_t rather than C longs. In particular: > > > * ints: Include/intobject.h:long ob_ival; > > As Tim says, this is way out of scope

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

2006-05-29 Thread Thomas Wouters
On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Neal Norwitz wrote:> minus comments, etc  yields several questions about whether some> values should use Py_ssize_t rather than C longs.  In particular:> * ints:  Include/intobject.h:long ob_ival; As Tim says, this is way out of scope for

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

2006-05-29 Thread Martin v. Löwis
Neal Norwitz wrote: > 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)

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

2006-05-29 Thread Tim Peters
[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

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

2006-05-29 Thread Tim Peters
[Neal Norwitz] >> * ints: Include/intobject.h:long ob_ival; [Thomas Wouters] > I considered asking about this before, as it would give '64-bit power' to > Win64 integers. It's a rather big change, though (lots of code assumes > PyInts fit in signed longs, which would be untrue then.) I expec

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

2006-05-29 Thread Thomas Wouters
On 5/29/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: * ints:  Include/intobject.h:long ob_ival;I considered asking about this before, as it would give '64-bit power' to Win64 integers. It's a rather big change, though (lots of code assumes PyInts fit in signed longs, which would be untrue then.

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

2006-05-28 Thread Neal Norwitz
$ 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 *);