[Python-Dev] PEP-393: request for keeping PyUnicode_EncodeDecimal()

["Martin v. Löwis"]

> What I'm looking for is a public function that is silently updated if
> python-dev decides to accept other numerical input. As I understand
> from your comments below, PyUnicode_EncodeDecimal() is frozen, so
> that function does indeed not help.
> 
> I would consider it reasonable for PyUnicode_TransformDecimalAndSpaceToASCII()
> to be documented as:
> 
>   "This function might accept different numerical input in the future."
> 
> 
> The reason is that some people would like to accept additional input
> (see #6632), while others would like to restrict input. If there is
> a function that will always track whatever will be decided, extension
> authors don't have to worry about being up-to-date.

I don't think it's possible to promise such a thing. Predictions
are difficult and all that. If somebody knew what the function should
do in the future, then it would be best to change it now to do that.

Rather expect that whenever functions get deprecated but not removed
that they keep the semantics they had, for use in code that relies
not only on the function name, but also on the function semantics (or
else there may not be a point in keeping the function at all if it
suddenly changes its behavior).

>>> 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.
> 
> I can find PyUnicode_TransformDecimalToASCII() in 3.2, but not
> PyUnicode_TransformDecimalAndSpaceToASCII().

Ah, so there is still a chance to make it private then. I plan to
go over all new APIs for 3.3, and will propose to make all those
private where nobody can argue for general utility. The longer the
function name, the less is the utility.

PyMartin_SendThisMessageAboutDecimalParsingToStefan-ly y'rs
Martin