[Python-Dev] New PEP: Using ssize_t as the index type

[Tim Peters]

[Martin v. Löwis]
...
> PEP: XXX
> Title: Using ssize_t as the index type

+1, and for Python 2.5, and the sooner done the less painful for all. 
Same concerns as Armin, where this is especially unattractive:

> The conversion codes 's#' and 't#' will output Py_ssize_t
> if the macro PY_SIZE_T_CLEAN is defined before Python.h
> is included, and continue to output int if that macro
> isn't defined.

Better to use a new gibberish character and deprecate the old one? 
Otherwise I'm afraid we'll be stuck supporting PY_SIZE_T_CLEAN
forever, and it's not good to have the meaning of a format string
depend on the presence or absence of a #define far away in the file.

A suggestion:

...

> In these cases, three strategies are available:
>
> *  statically determine that the size can never exceed an int
>    (e.g. when taking the sizeof a struct, or the strlen of
>    a file pathname). In this case, add a debug assert() that
>    the value is indeed smaller than INT_MAX, and cast the
>    value to int.

That can be done in one gulp via:

    some_int = Py_SAFE_DOWNCAST(some_value, Py_ssize_t, int);

In a debug build that will assert-fail if some_value loses info when
cast from Py_ssize_t to int.  If people had been careful, this would
already be in use when casting from size_t to int;  there's even one
place in unicodeobject.c that does so ;-).