Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34k
bpo-36346: Add Py_DEPRECATED to deprecated unicode APIs#20878
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
methane commented Jun 15, 2020 • edited by bedevere-bot
Loading Uh oh!
There was an error while loading. Please reload this page.
edited by bedevere-bot
Uh oh!
There was an error while loading. Please reload this page.
methane commented Jun 15, 2020
Warnings in |
methane commented Jun 15, 2020
aeros left a comment • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
methane commented Jun 15, 2020
Another way to suppress warning is adding private function without warning, like |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ambv commented Jun 16, 2020
I'm fine with having this in 3.9 |
Uh oh!
There was an error while loading. Please reload this page.
vstinner commented Jun 17, 2020
About the "_impl" suffix discussion: I wrote PR #20931 to remove it from _PyObject_GC_TRACK() :-) |
vstinner left a comment
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:
| #definePyUnicode_WSTR_LENGTH(op) _PyUnicode_get_wstr_length((PyObject*)op) | |
| #definePyUnicode_WSTR_LENGTH(op) _PyUnicode_get_wstr_length(_PyObject_CAST(op)) |
methane commented Jun 17, 2020
Thank you for your review! |
miss-islington commented Jun 17, 2020
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]>
bedevere-bot commented Jun 17, 2020
GH-20932 is a backport of this pull request to the 3.9 branch. |
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
vstinner commented Jun 17, 2020
The change broke multiple buildbots on master, so I rejected the 3.9 backport PR. |
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
bedevere-bot commented Jun 17, 2020
|
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)
https://bugs.python.org/issue36346