-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
bpo-43753: Add Py_Is() and Py_IsNone() functions #25227
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
Conversation
|
I rebased my PR and I reimplemented Py_Is() as a macro. |
|
And I added unit tests. |
|
@markshannon: so are you against the principle of adding this macro and using it? Or can I merge it? |
|
@corona10 @serhiy-storchaka @methane @pitrou: Do you think that these 4 functions are useful? See https://bugs.python.org/issue43753 for the rationale. It's mostly about helping to write C extensions compatible with PyPy, and prepare the bright future of HPy. |
|
Can this be added to the stable ABI even though it's a macro? |
I don't see the point of adding it to the ABI in CPython right now. Can you please elaborate? I mostly care about the API. Raymond is concerned by the risk of a negative impact on performance: https://bugs.python.org/issue43753#msg390379 As I only care about the API, I'm perfectly fine with a macro. PyPy is free to implement it as a function if they want. |
|
But then people targetting the stable ABI can't use this API? If the goal is to maximize usage, then it should be part of the ABI... |
Ok, I get your point. That's why I declared Py_NewRef() and Py_XNewRef() as static inline functions and regular functions. I modified tests on these functions to test the macros (static inline functions) and the function implementations. |
|
I prepared a pull request on my pythoncapi_compat project to add Py_Is(), Py_IsNone(), Py_IsTrue() and Py_IsFalse() to Python 3.9 and older and to PyPy: python/pythoncapi-compat#8 ;-) I will merge it if this PR is merged. |
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.
I am +1 on adding Py_Is(). It can be quite useful for some use-cases.
But other variations are not convinced to me.
If I understand your intention correctly, we may create all the variations of PyIsXXX for singleton objects. When considering adding is easy but deprecating and removing is hard, I would like to add Py_Is() API only.
if we add _Py_IsXXX variations as the private API, I am okay to add those :)
Ok.
I don't propose to add a variation for all singletons. Only for these 3 which are the common (None, True, False). I proposed Py_IsNone(), Py_IsTrue(), Py_IsFalse() to make the transition to Py_Is() more pleasant. IMO if we only add Py_Is(), it's harder to read code which repeat I removed Py_IsNone(), Py_IsTrue(), Py_IsFalse(). I also modified Python/ceval.c in this PR, so you can see the change in practice. So what do you prefer? Ony Py_Is() or with 4 functions? Example with the current C API: Only with Py_Is(): With Py_IsNone(), Py_IsTrue() and Py_IsFalse(): |
|
I think having the 4 functions is ok. |
|
After I wrote my comment with examples showing the 3 APIs, I changed my mind. I really want Py_IsNone(), Py_IsTrue(), Py_IsFalse(). Having to replace whereas replacing Even if the 3 functions are just helper, I would like to add them. |
|
"Py_IsTrue(x): Test if an object is True." Hum, I was confused by this description. I rewrote it mentioning the singleton word: => "Py_IsTrue(x): Test if an object is the True singleton." IMO the description now avoids any possible confusion with PyObject_IsTrue(x). |
Misc/NEWS.d/next/C API/2021-04-06-20-52-44.bpo-43753.xUsHp1.rst
Outdated
Show resolved
Hide resolved
Objects/object.c
Outdated
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.
I am not super conviced. Why would people would like to use Py_Is if is going to be slower than just pointer comparison?
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.
The intent is correctness if you care about other Python implelentations than CPython. If you don't care, well, don't use it :-)
corona10
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.
I think having the 4 functions is ok. x is None has been a recommended idiom for at least 20 years.
I don't propose to add a variation for all singletons. Only for these 3 which are the common (None, True, False).
I read the comments and I also change my mind to export those APIs.
So +1
Add the Py_Is(x, y) function to test if the 'x' object is the 'y' object, the same as "x is y" in Python. Add also the Py_IsNone(), Py_IsTrue(), Py_IsFalse() functions to test if an object is, respectively, the None singleton, the True singleton or the False singleton.
|
@pablogsal: Oh, thank you for fixing my English :-) I addressed your review. About exposing Py_Is() and Py_IsNone() as a regular function: please see @pitrou's previous comment. |
|
The docs CI failed with: Does anyone understand what's wrong with my NEWS entry? |
I think this warning was due to #25335 |
Oh ok. I merged my PR in this case. |
|
Thanks @erlend-aasland @pitrou @corona10 and @pablogsal for your useful reviews! |
Add Py_Is(x, y) function testing if the 'x' object is the 'y' object,
same than "x is y" in Python. Add also Py_IsNone(), Py_IsTrue(),
Py_IsFalse() functions to test if an object is, respectively, the
None` singleton, the True singleton or the False singleton.
https://bugs.python.org/issue43753