Originally C API didn't use the const qualifier. Over few last years the const qualifier was added to C API if that preserved backward compatibility. For example input "char *" parameters were changed to "const char *". This makes C API compatible with C++, eliminates C compiler warnings, and helps to found possible errors. Now I have started to make changes that are not absolute compatible, and can need modifying third-party code (but unlikely). * The const qualifier was added to "char *" fields name and doc of some structures. They always point to C string literals. https://bugs.python.org/issue28761 * The const qualifier was added to private global variable _Py_PackageContext. https://bugs.python.org/issue28748 Now I'm going to add the const qualifier to the result of PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8(). These functions return a reference to internal cached UTF8 representations of a string. It should never be modified. https://bugs.python.org/issue28769 Later I'm planning following changes: * Add the const qualifier to the result of functions that return references to internal representation of immutable objects, like PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally can modify the content of immutable objets, this is very dangerous, because this can invalidates invariants and cached values. Third-party code shouldn't do this. * Add the const qualifier to the format field of Py_buffer. It is a reference to C string literal or to the content of bytes object. Mutating its content is an error. Only _testbuffer overuses the format field of internal Py_buffer object for owning a reference to allocated memory. But this is not leaked outside. What are you think about this?