Skip to content
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

implement ffi/cpython/pystate #1687

Merged
merged 11 commits into from
Jun 24, 2021
Merged

implement ffi/cpython/pystate #1687

merged 11 commits into from
Jun 24, 2021

Conversation

mejrs
Copy link
Member

@mejrs mejrs commented Jun 23, 2021

Per #1675

Also:

  • adds a bit more documentation to /ffi
  • makes the cpython modules pub(crate) to avoid double glob imports (is this OK?)


/// Not actually a public field
/// Also, it has an additional argument in 3.9
#[cfg(not(Py_3_9))]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that this is a good way to handle this, any suggestions?

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be restricting the ffi::cpython modules to pub(crate). They're already public in the CPython API, so I think it's correct for them to be pub, not pub(crate).

Also, I think that we should probably remove the PyInterpreterState struct as that looks scary - see other comment.

@@ -7,10 +8,29 @@ use std::os::raw::{c_int, c_long};
pub const MAX_CO_EXTRA_USERS: c_int = 255;

#[repr(C)]
#[derive(Copy, Clone)]
#[derive(Debug, Copy, Clone)]
pub struct PyInterpreterState {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this looks dangerously broken, because it doesn't match at all the full contents of the corresponding struct in the Python headers: https://github.com/python/cpython/blob/af5fb6706219d7949c1db5c9f2b7da53198123f3/Include/internal/pycore_pystate.h#L67

Appreciate that this existed before you wrote this PR, but I don't think editing this struct in this PR achieves much.

As it's an internal type (and probably very different on PyPy),I think we should just replace with an opaque type:

opaque_struct!(PyInterpreterState);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@mejrs
Copy link
Member Author

mejrs commented Jun 23, 2021

I don't think we should be restricting the ffi::cpython modules to pub(crate). They're already public in the CPython API, so I think it's correct for them to be pub, not pub(crate).

Their contents would still be public, just not the modules themselves.

Currently when you search for something that is defined in the cpython module this is what you see, because it's glob imported twice:

image

@davidhewitt
Copy link
Member

Their contents would still be public, just not the modules themselves.

Currently when you search for something that is defined in the cpython module this is what you see, because it's glob imported twice:

👍 I'm persuaded; also the modules in pyo3::ffi are not pub, so this is consistent.

@davidhewitt
Copy link
Member

Happy to merge this once conflict caused by #1692 is resolved (sorry!)

@messense messense merged commit 455cc95 into PyO3:main Jun 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

_PyFrameEvalFunction has different definitions in Python 3.8 and Python 3.9
3 participants