> longobject.c still used PyUnicode_EncodeDecimal() until 10 months
> ago (8304bd765bcf). I missed the PyUnicode_TransformDecimalToASCII()
> commit, probably because #10557 is still open.
>
> That's why I wouldn't like to implement the function myself at least
> until the API is settled.
I don't understand. If you implement it yourself, you don't have to
worry at all what the API is. Py_UNICODE_TODECIMAL has been around
for a long time, and will stay, no matter how number parsing is
implemented. That's all you need.
out = malloc(PyUnicode_GET_LENGTH(in)+1);
for (i = 0; i < PyUnicode_GET_LENGTH(in); i++) {
Py_UCS4 ch = PyUnicode_READ_CHAR(in, i);
int d = Py_UNICODE_TODIGIT(ch);
if (d != -1) {
out[i] == '0'+d;
continue;
}
if (ch < 128)
out[i] = ch;
else {
error();
return;
}
}
out[i] = '\0';
OTOH, *if* number parsing is ever updated (e.g. to consider alternative
decimal points), PyUnicode_EncodeDecimal still won't be changed - it
will continue to do exactly what it does today.
> Will PyUnicode_TransformDecimalAndSpaceToASCII() be public?
It's already included in 3.2, so it can't be removed that easily.
I wish it had been private, though - we have way too many API functions
dealing with Unicode.
Regards,
Martin
_______________________________________________
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
