Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
PEP 623: Remove wstr from Unicode object#1462
Conversation
No description provided. |
This PEP makes me sad. I dislike having to wait until 2025 (Python 3.14) to remove the last deprecated functions :-( I would prefer to target Python 3.12 for removal, and deprecate all at once in Python 3.10. |
I prefer to new plan: I'm more excited to see the removal in 2023 (Python 3.12) rath in 2025 (Python 3.14)! |
| @@ -0,0 +1,167 @@ | |||
| PEP: 629 | |||
| Title: Remove wstr from Unicode | |||
This comment has been minimized.
This comment has been minimized.
vstinnerJun 25, 2020 MemberAt the beginning, the PEP was focused on the wstr member. Now it also removes PyUnicode_READY(). But the PEP title can be changed to:
"Remove the legacy Unicode C API"
At the beginning, the PEP was focused on the wstr member. Now it also removes PyUnicode_READY(). But the PEP title can be changed to:
"Remove the legacy Unicode C API"
This comment has been minimized.
This comment has been minimized.
methaneJun 25, 2020 Author MemberI want to focus on APIs using wstr, because most APIs using Py_UNICODE can be removed without PEP.
I want to focus on APIs using wstr, because most APIs using Py_UNICODE can be removed without PEP.
| these deprecated APIs.[1]_ | ||
| This PEP is planning removal of``wstr``, and``wstr_length`` with | ||
| deprecated APIs using these members by Python 3.12. |
This comment has been minimized.
This comment has been minimized.
vstinnerJun 25, 2020 MemberWhen I readhttps://www.python.org/dev/peps/pep-0393/#deprecations-removals-and-incompatibilities and your PEP, it's non-obvious why functions usingPy_UNICODE* like PyUnicode_Encode() are not scheduled for removal by this PEP. Even for me who knows well Unicode internals :-)
First of all, doyou care of removing these functions in the "short term" (Python 3.12) or long term (later)? Or do you want to keep them for now? If you want to keep them, please just add a sentence somewhere to explain that.
For example, explain that the PEP is limited to removing PyUnicode_WCHAR_KIND and all related APIs, for reasons listed in the PEP. But functions withPy_UNICODE* don't use PyUnicode_WCHAR_KIND and so are out of the scope of this PEP.
When I readhttps://www.python.org/dev/peps/pep-0393/#deprecations-removals-and-incompatibilities and your PEP, it's non-obvious why functions usingPy_UNICODE* like PyUnicode_Encode() are not scheduled for removal by this PEP. Even for me who knows well Unicode internals :-)
First of all, doyou care of removing these functions in the "short term" (Python 3.12) or long term (later)? Or do you want to keep them for now? If you want to keep them, please just add a sentence somewhere to explain that.
For example, explain that the PEP is limited to removing PyUnicode_WCHAR_KIND and all related APIs, for reasons listed in the PEP. But functions withPy_UNICODE* don't use PyUnicode_WCHAR_KIND and so are out of the scope of this PEP.
This comment has been minimized.
This comment has been minimized.
methaneJun 25, 2020 Author MemberFirst of all, doyou care of removing these functions in the "short term" (Python 3.12) or long term (later)? Or do you want to keep them for now? If you want to keep them, please just add a sentence somewhere to explain that.
I want to remove most of them before Python 3.12. I don't want to make Python 3.12 big breaking change.
Most APIs are documented as deprecated since Python 3.3, and markedPy_DEPRECATED since Python 3.6. Most of them can be removed in 3.10.
For example, explain that the PEP is limited to removing PyUnicode_WCHAR_KIND and all related APIs, for reasons listed in the PEP. But functions withPy_UNICODE* don't use PyUnicode_WCHAR_KIND and so are out of the scope of this PEP.
PyUnicode_AsUnicode() and "u" format in PyArg_ParseTuple are not relating to PyUnicode_WCHAR_KIND, butwstr.
First of all, doyou care of removing these functions in the "short term" (Python 3.12) or long term (later)? Or do you want to keep them for now? If you want to keep them, please just add a sentence somewhere to explain that.
I want to remove most of them before Python 3.12. I don't want to make Python 3.12 big breaking change.
Most APIs are documented as deprecated since Python 3.3, and markedPy_DEPRECATED since Python 3.6. Most of them can be removed in 3.10.
For example, explain that the PEP is limited to removing PyUnicode_WCHAR_KIND and all related APIs, for reasons listed in the PEP. But functions with
Py_UNICODE*don't use PyUnicode_WCHAR_KIND and so are out of the scope of this PEP.
PyUnicode_AsUnicode() and "u" format in PyArg_ParseTuple are not relating to PyUnicode_WCHAR_KIND, butwstr.
This comment has been minimized.
This comment has been minimized.
vstinnerJun 25, 2020 MemberMost APIs are documented as deprecated since Python 3.3, and marked Py_DEPRECATED since Python 3.6. Most of them can be removed in 3.10.
I'm not sure that people are paying attention to compiler warnings emitted by Py_DEPRECATED(). Do you think that it's worth it to start emiting a DeprecationWarning in Python 3.10, and remove these functions in Python 3.12, or maybe already in Python 3.11?
Most APIs are documented as deprecated since Python 3.3, and marked Py_DEPRECATED since Python 3.6. Most of them can be removed in 3.10.
I'm not sure that people are paying attention to compiler warnings emitted by Py_DEPRECATED(). Do you think that it's worth it to start emiting a DeprecationWarning in Python 3.10, and remove these functions in Python 3.12, or maybe already in Python 3.11?
This comment has been minimized.
This comment has been minimized.
methaneJun 25, 2020 Author MemberI don't think so.
For example, PyLong_FromUnicode doesn't execute arbitrary code. It doesn't release GIL too.
If we emit warning from the function, now the function will run arbitrary code (warning filter).
It is breaking change too. But compile error must be safe than runtime warning.
We can revert the removal anyway.
I don't think so.
For example, PyLong_FromUnicode doesn't execute arbitrary code. It doesn't release GIL too.
If we emit warning from the function, now the function will run arbitrary code (warning filter).
It is breaking change too. But compile error must be safe than runtime warning.
We can revert the removal anyway.
The implementation of the Python str types and codecs take more than 21k lines of C code. I would prefer to remove as much deprecated code as possible to reduce the maintenance burden. The problem is that I don't know how many C extension modules still use it. Maybe we can start by deprecating all of them in 3.10, announce removal in 3.12, but postpone removal of some functions using It sounds relevant to put it in the same PEP since it's also related to Unicode C API, but I can also understand if you prefer to keep the PEP as small as possible. If you don't want to put it in the same PEP, I'm not sure if I should write another PEP... or simply deprecate/remove with no PEP :-) A PEP helps to communicate our intent and make deprecation more visible. |
LGTM, but I suggest to change the PEP number to 623. You may try to merge the PR ASAP to reserve the PEP number, we can continue to discuss it after it's merged ;-) |
A typo and suggestion |
9ea076f intopython:master| these deprecated APIs.[1]_ | ||
| This PEP is planning removal of``wstr``, and``wstr_length`` with | ||
| deprecated APIs using these members by Python 3.12. | ||
| Deprecated APIs doesn't use the members are out of scope because | ||
| Deprecated APIswhichdoesn't use the members are out of scope because |
This comment has been minimized.
This comment has been minimized.
hugovkJun 25, 2020 Contributor-Deprecated APIs which doesn't use the members are out of scope because+Deprecated APIs which don't use the members are out of scope because
-Deprecated APIs which doesn't use the members are out of scope because+Deprecated APIs which don't use the members are out of scope because
Verified
[8]ページ先頭