[Python-Dev] Type of range object members

[Guido van Rossum]

On 8/14/06, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
>
> On Aug 14, 2006, at 7:32 PM, Guido van Rossum wrote:
>
> > Methinks that as long as PyIntObject uses long (see intobject.h)
> > there's no point in changing this to long.
>
> I guess you meant "changing this to Py_ssize_t ".

Yup, sorry.

> I don't understand
> why the type used by PyIntObject is relevant here.

Because the only way to create one (in 2.5 or before) is by passing it
a Python int.

> Range object's
> "start" is logically  an index, but int object's "ob_ival" is not.
> Since PyIntObject's is definition is exposed by Python.h, changing
> the type of ob_ival will probably break a lot of code.  This
> reasoning does not apply to the range object.

But since the start and end come from a Python int, what advantage
would it have to use Py_ssize_t instead? We know sizeof(long) <=
sizeof(Py_ssize_t).

> Since on most platforms ssize_t is the same as long, the choice
> between the two is just a matter of self-documenting code.  Speaking
> of which, I find it unfortunate that the name Py_ssize_t was selected
> for the typedef.  I would prefer Py_index_t.  The first time I saw
> Py_ssize_t, I did not notice the double 's' and thought it was an
> unsigned type.

Blame the C standards committee -- they introduced ssize_t in C99.

> On the second look, I've realized that it is signed
> and started wondering why not ptrdiff_t.

Because it is not used for the difference of pointers?

Frankly, you're about 6 months too late with naming concerns. It's not
going to change now. The PEP has been discussed and the code reviewed
ad infinitum. We're only looking for bugs now, and so far the issue
you've brought up decidedly falls in the category "non-bug".

> I understand that ssize_t
> is defined by POSIX as the return type of functions such as "read"
> that can return either size or -1 for error.  I don't think POSIX
> mandates sizeof(size_t) == sizeof(ssize_t), but I may be wrong.   I
> would agree that ptrdiff_t, although standard C, is not a very
> intuitive name, but ssize_t is even less clear.

Water under the bridge.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)