This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients martin.panter, ncoghlan, serhiy.storchaka, vstinner
Date 2016-11-22.08:59:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1479805150.62.0.0784859626331.issue28769@psf.upfronthosting.co.za>
In-reply-to
Content
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 ;-)
History
Date User Action Args
2016-11-22 08:59:10vstinnersetrecipients: + vstinner, ncoghlan, martin.panter, serhiy.storchaka
2016-11-22 08:59:10vstinnersetmessageid: <1479805150.62.0.0784859626331.issue28769@psf.upfronthosting.co.za>
2016-11-22 08:59:10vstinnerlinkissue28769 messages
2016-11-22 08:59:10vstinnercreate