[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 ;-).
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om