ffi cleanup: abstract.h - #1436
Conversation
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
👍 this is a great catch, thanks!
|
I'm going to rebase this, force-push and merge shortly. Thanks again. |
Some functions available in earlier versions were moved to this directory, but are still valid.
|
Hmm, after rebasing we still have issues: the "macro" forms of |
Ouch. I've double-checked and PyIter_Check in 3.7 tries to use the contents of the opaque PyTypeObject, even under the limited API. I wonder why nobody noticed? I think the best thing to do here is to remove the functions again :( will do this by the weekend. |
While these are defined as macros in the Python C API, they rely on access to the PyTypeObject structure, which is not part of the limited API for those versions.
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
Thanks for finishing this off.
| // Defined as this macro in Python 3.6, 3.7 limited API, but relies on | ||
| // non-limited PyTypeObject. Don't expose this since it cannot be used. | ||
| #[cfg(not(any(Py_LIMITED_API, PyPy)))] | ||
| #[inline] | ||
| pub unsafe fn PyIter_Check(o: *mut PyObject) -> c_int { |
3 participants
This PR makes PyIter_Check available to Python earlier than 3.8 under the limited API.
This was due to some interaction between the
cfg(not(Py_LIMITED_API)onffi::cpython, and the cfg on PyIter_Check within theffi::cpythonmodule.However, it's always been in the limited API: as a macro before 3.8, and as a function since 3.8. Under the non-limited API it's always a macro.
Consequently we can implement PyTryFrom for PyIterator for all versions. I've (speculatively) commented out the cfg preventing that.
Similar changes for PyIndex_Check.