-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-36346: Add Py_DEPRECATED to deprecated unicode APIs #20878
Conversation
Warnings in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regardless of whether the removal occurs in 3.11 or needs to be delayed for any reason, I think un-commenting the compiler warnings for 3.9 can only help users.
However, from looking at the blame and locating the commit that added the comments, it's not completely clear to me as to why it was done: 3c8724f. It looks like support for the macro Py_DEPRECATED()
was added to MSVC, and while working on that, these were added as comments. It appears that some of the other ones were added by @vstinner.
What is the purpose of adding them as comments in the first place? Is this just done to avoid scope creep in the other PRs, while still marking it as "to do" for later? Or is there some convention with regards to adding it as a comment before an actual warning?
Either way though, +1 for un-commenting the existing Py_DEPRECATED()
macros for the unicode APIs that are being removed. Without the warnings in 3.9, I think a 3.11 removal would be too soon.
Another way to suppress warning is adding private function without warning, like |
I'm fine with having this in 3.9 |
Misc/NEWS.d/next/C API/2020-06-17-11-24-00.bpo-36346.fTMr3S.rst
Outdated
Show resolved
Hide resolved
About the "_impl" suffix discussion: I wrote PR #20931 to remove it from _PyObject_GC_TRACK() :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the multiple updates, the PR now looks much better! I prefer the new code of static inline macros ;-)
It's easier to read, variables have a well defined scope, and the return type is now clearly void ;-) Once I tried to convert all unicodeobject.h macros into static inline functions, but it's giant work and it's tricky to not introduce new compiler warnings :-(
I just added a minor suggestion about _PyObject_CAST().
((PyASCIIObject*)op)->length : | ||
((PyCompactUnicodeObject*)op)->wstr_length; | ||
} | ||
#define PyUnicode_WSTR_LENGTH(op) _PyUnicode_get_wstr_length((PyObject*)op) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might use _PyObject_CAST() macro:
#define PyUnicode_WSTR_LENGTH(op) _PyUnicode_get_wstr_length((PyObject*)op) | |
#define PyUnicode_WSTR_LENGTH(op) _PyUnicode_get_wstr_length(_PyObject_CAST(op)) |
Thank you for your review! |
Thanks @methane for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
Co-authored-by: Kyle Stanley <[email protected]> Co-authored-by: Victor Stinner <[email protected]> (cherry picked from commit 2c4928d) Co-authored-by: Inada Naoki <[email protected]>
GH-20932 is a backport of this pull request to the 3.9 branch. |
|
|
|
The change broke multiple buildbots on master, so I rejected the 3.9 backport PR. |
|
|
|
|
|
|
Co-authored-by: Kyle Stanley <[email protected]> Co-authored-by: Victor Stinner <[email protected]> (cherry picked from commit 2c4928d)
Co-authored-by: Kyle Stanley <[email protected]> Co-authored-by: Victor Stinner <[email protected]> (cherry picked from commit 2c4928d)
Co-authored-by: Kyle Stanley <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
https://bugs.python.org/issue36346