PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8() return a reference to cached readonly UTF-8 representation of a string. Changing the content of the UTF-8 representation is an error. Proposed patch makes these functions returning "const char *" rather of "char *" to force this restriction.

This is backward-incompatible change. Since PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8() can return an error, it is more likely that the result is saved in a local variable rather than passing to other function. If the type of this variable is "char *" rather than "const char *", this would cause a compiler error. The fix is simple -- just add the const qualifier to the local variable declaration (more preferable) or cast the result of PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8() to "char *".

Both functions are not in stable API.

No opinion if this is a good change to make, but I left some review suggestions

Hum, I would like to discuss this topic on python-dev.

Changing PyUnicode_AsUTF8() alone is fine, but the issue with changing return type is that the const has to be propagated to callers, and then to callers of callers, etc. For example, if your patch, you cast (const char*) to (char*) to call tp_getattr.

The question is why tp_getattr doesn't use (const char*)?

I would prefer to take an overall decision for the C API, to decide if it's ok to "propagate" const changes in various places of the C API.

About the stable API: in fact, it's more a stable *ABI*: PEP-384, "Defining a Stable ABI". At the ABI level, there is no more "const". So it's perfectly fine to add or remove const, we already did that in the past.

Obviously, such change should only be done in Python 3.7.

For me, the main issue is for Python modules compiled with -Werror: if they upgrade to Python 3.7, the compilation will fail because they cast (const char*) to (char*) implicitly, which is a warning when using -Wall -Wextra, warning converted to a compilation error.

That's why I suggest to have an overall discussion on const on python-dev ;-)

Hum, sorry, my opinion on const is not obvious in my previous message: I like const :-) I want to use const everywhere! I still "believe" (I don't know if it's true or not) that const helps a lot compilers to optimize the code.

I don't know if it helps for a single variable. Maybe it's more helpful on a whole structure and/or pointers to avoid complex heuristics on aliasing.

My first attempt to design the _PyBytesWriter API was a big mistake: it was much slower: issue bpo-17742. I understood that using a structure instead of multiple variables does stress the compiler who doesn't know if some optimizations are still save. In case of doubt, the compiler doesn't optimize to avoid generating invalid code.

Opened a topic on Python-Dev: https://mail.python.org/pipermail/python-dev/2016-December/147029.html.

Addressed comments, added the versionchanged directives, the code in _decimal.c is now more obvious.

Stefan, what are your thoughts about this? The patch touches _decimal.c.

For _decimal I'm happy with just the cast from the first patch -- you have a one line diff and it's easy to see the focus of the issue.

New changeset 0d89212941f4 by Serhiy Storchaka in branch 'default':
Issue bpo-28769: The result of PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8()
https://hg.python.org/cpython/rev/0d89212941f4

New changeset 6e67695 by Victor Stinner in branch 'master':
timemodule.c: Cast PyUnicode_AsUTF8() to char* (bpo-1294)
6e67695