I was talking about the deprecated usage, with str=NULL ;-)
Sure, we can raise an error later.
Victor Le ven. 7 sept. 2018 à 19:09, Antoine Pitrou <antoine@python.org> a écrit :
Le 07/09/2018 à 19:05, Victor Stinner a écrit :
Le ven. 7 sept. 2018 à 18:31, Antoine Pitrou <antoine@python.org> a écrit :
Why is PyUnicode_FromStringAndSize a problem?
Well, it's not a problem: it works and is supported :-) But this function creates a string in the legacy Py_UNICODE* format.
Why can't we simply change the implementation?
It's just an example of API of technical debt and legacy API.
The documentation for PyUnicode_FromStringAndSize() says:
""" Create a Unicode object from the char buffer u. The bytes will be interpreted as being UTF-8 encoded. The buffer is copied into the new object. If the buffer is not NULL, the return value might be a shared object, i.e. modification of the data is not allowed.
If u is NULL, this function behaves like PyUnicode_FromUnicode() with the buffer set to NULL. This usage is deprecated in favor of PyUnicode_New(). """
So there is a deprecated usage which can just be turned into an error. Otherwise I don't see the problem. PyUnicode_FromStringAndSize() exposes a reasonable feature and is necessary for many applications.
Regards
Antoine.
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org