Should `Py_Is` be preferred to `==`?

[colesbury (Sam Gross)]

@steve-s

There is already PyStackRef_Is in CPython…

No, there’s no PyStackRef_Is in CPython. I removed it over a month ago because every usage was incorrect. It also wasn’t equivalent to Python’s is operator.

@steve-s

I think we can say that an eventuality where we would like to migrate code from == to Py_Is is not some wild theoretical prediction unlikely to materialize.

I don’t agree with this characterization: Py_Is operates on PyObject * data types. If we make further use of tagged pointers, we will use a different data type and different macros or functions, not Py_Is.

[steve-s (Stepan Sindelar)]

@colesbury

No, there’s no PyStackRef_Is in CPython. I removed it over a month ago because every usage was incorrect. It also wasn’t equivalent to Python’s is operator.

Ah, thank you for the correction!

@colesbury

I don’t agree with this characterization: Py_Is operates on PyObject * data types. If we make further use of tagged pointers, we will use a different data type and different macros or functions, not Py_Is.

What I mean is that porting code that operates on PyObject* to some other API with its own representation of Python objects, like PyStackRef, and its own version of Py_Is like PyStackRef_Is.

Admittedly, such API should make == comparison a compiler error. For example, HPy defines the HPy type in such way. So a migration can be also guided by compiler errors.