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 Arfrever, Michael.Felt, eryksun, ezio.melotti, pitrou, serhiy.storchaka, vstinner
Date 2016-11-07.09:05:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1478509530.96.0.107771287808.issue19569@psf.upfronthosting.co.za>
In-reply-to
Content
> Proposed patch marks most deprecated functions. Code is rewritten for using non-deprecated functions if possible. Unfortunately some deprecated function still are used in the code and can't be easier replaced. They are left not marked.

Hum, I suggest to first update these functions instead of using compiler tricks to ignore deprecation warnings. Once CPython code base doesn't use deprecated functions anymore, deprecate functions (emit a warning).

> All these cases needs separate issues.

I agree :-)

* PyEval_ReleaseLock() is used in Python/pystate.c. It can't be replaced with PyEval_ReleaseThread() since the latter don't accept NULL.

Does this feature (accept NULL) make sense outside CPython core? If not, add a private function exposing the feature.

> * Py_UNICODE (currently an alias of wchar_t) is used in a number of deprecated functions and bridges between deprecated and new APIs. Maybe it can be just replaced with wchar_t.

Which functions are bridges?

Would it be possible to split these bridges into two functions: a private function which doesn't emit a warning, and a public deprecated function which calls the private function?

I dislike the idea of replacing Py_UNICODE* with wchar_t*.


> * Macros PyUnicode_GET_SIZE, PyUnicode_GET_DATA_SIZE, PyUnicode_AS_UNICODE, PyUnicode_AS_DATA, functions PyUnicode_AsUnicode and PyUnicode_AsUnicodeAndSize are used in a number of places. They can't be easily replaced with wchar-based functions since they return a borrowed reference to cached representation.

We must not used these functions in CPython core, except to develop the "bridges" you mentionned before. Please open a separated issue to discuss how to handle the deprecation of the functions using Py_UNICODE*.


* PyUnicode_FromUnicode, PyUnicode_EncodeDecimal and PyUnicode_TransformDecimalToASCII are used only in Modules/_testcapimodule.c. I think we should write tests for modern APIs and eliminate tests for deprecated APIs. Or temporary silence compiler warning in test functions.

* _PyUnicode_ToLowercase, _PyUnicode_ToUppercase and corresponding public macros Py_UNICODE_TOLOWER and Py_UNICODE_TOUPPER are used in Modules/_sre.c (this is a bug in regex implementation). The problem is that more modern functions _PyUnicode_ToLowerFull and _PyUnicode_ToUpperFull is a private API.

"Py_UCS4 _PyUnicode_ToLowercase(Py_UCS4 ch)" doesn't use Py_UNICODE, what is the issue?

"#define Py_UNICODE_ISDECIMAL(ch) _PyUnicode_IsDecimalDigit(ch)" this macro doesn't use the Py_UNICODE type, so we don't have to deprecate it.

Do you want to deprecate functions like Py_UNICODE_ISDECIMAL(ch)?
History
Date User Action Args
2016-11-07 09:05:31vstinnersetrecipients: + vstinner, pitrou, ezio.melotti, Arfrever, serhiy.storchaka, eryksun, Michael.Felt
2016-11-07 09:05:30vstinnersetmessageid: <1478509530.96.0.107771287808.issue19569@psf.upfronthosting.co.za>
2016-11-07 09:05:30vstinnerlinkissue19569 messages
2016-11-07 09:05:30vstinnercreate