[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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
