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

ffi module cleanup #1338

Merged
merged 10 commits into from Dec 27, 2020
Merged

ffi module cleanup #1338

merged 10 commits into from Dec 27, 2020

Conversation

nw0
Copy link
Contributor

@nw0 nw0 commented Dec 24, 2020

Partial fix for #1289, as suggested in #1289 (comment)

use crate::ffi::object::PyObject;
use crate::ffi::pystate::{PyThreadState, Py_tracefunc};
use crate::ffi::pystate::PyThreadState;
use std::os::raw::{c_char, c_int, c_void};

extern "C" {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can't select the exact line, but PyEval_CallObjectWithKeywords is marked deprecated in 3.9. However, if I mark it with #[cfg_attr(Py_3_9, deprecated(note = "Python 3.9"))], I can't compile due to deny(warnings) on this crate (it's used by PyEval_CallObject below).

Maybe we could consider being a bit more specific with the crate's deny attribute? https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deny-warnings.md

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, I recently added this and I agree it's now an antipattern.

I've opened #1340 to remove the attribute.

As specifically here, I think we will need to put #[allow(deprecated)] on the call inside PyEval_CallObject so that this passes CI. Mildly annoying, but hey!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is fine, I think. I think the only gotcha is that we need to add the deprecation to PyEval_CallObject as well.

src/ffi/code.rs Outdated
crate::ffi::tupleobject::PyTuple_GET_SIZE((*op).co_freevars)
}
// TODO: newtype
pub use crate::ffi::PyCodeObject;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The definition in Include/code.h is typedef struct PyCodeObject PyCodeObject, where the actual def is in Include/cpython/code.h.

I plan to change this into a newtype, but this requires some other code changes I'm not prepared to make yet. Just making a note here.

Copy link
Member

Choose a reason for hiding this comment

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

I think what we need is

#[cfg(Py_LIMITED_API)]
opaque_struct!(PyCodeObject);

Also, we have to remove #[cfg(not(Py_LIMITED_API)] from mod code;.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've made this change

Copy link
Member

Choose a reason for hiding this comment

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

Also, let's remove pub use crate::ffi::PyCodeObject;.
Since we import all items in mod.rs, this is not so mearningful.

@nw0
Copy link
Contributor Author

nw0 commented Dec 24, 2020

Hmm, I'm not sure what to make of

 Falsifying example: test_datetime_from_timestamp(
    dt=datetime.datetime(3001, 1, 19, 0, 0, fold=1),
)

(from failing python3.6-x86 windows-latest). Is this something you know about or do I need to try smaller changes?

Copy link
Member

@kngwyu kngwyu left a comment

Choose a reason for hiding this comment

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

Thanks!
I don't think the datetime test failure is related to this change and we need to file it as a separate issue.

src/ffi/code.rs Outdated
crate::ffi::tupleobject::PyTuple_GET_SIZE((*op).co_freevars)
}
// TODO: newtype
pub use crate::ffi::PyCodeObject;
Copy link
Member

Choose a reason for hiding this comment

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

I think what we need is

#[cfg(Py_LIMITED_API)]
opaque_struct!(PyCodeObject);

Also, we have to remove #[cfg(not(Py_LIMITED_API)] from mod code;.

src/ffi/mod.rs Outdated Show resolved Hide resolved
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.

Thanks very much for kicking this efforts off! ❤️ 🚀

I think once we've got that last deprecated attribute in place, this batch of cleanups is ready to merge? 🙇

use crate::ffi::object::PyObject;
use crate::ffi::pystate::{PyThreadState, Py_tracefunc};
use crate::ffi::pystate::PyThreadState;
use std::os::raw::{c_char, c_int, c_void};

extern "C" {
Copy link
Member

Choose a reason for hiding this comment

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

Thanks, I recently added this and I agree it's now an antipattern.

I've opened #1340 to remove the attribute.

As specifically here, I think we will need to put #[allow(deprecated)] on the call inside PyEval_CallObject so that this passes CI. Mildly annoying, but hey!

@davidhewitt
Copy link
Member

The deprecated stuff should work better if you rebase on master.

Also, if you are willing to add a CHANGELOG entry documented the new and deprecated APIs, that'd be excellent 🙏

@nw0
Copy link
Contributor Author

nw0 commented Dec 26, 2020

All done, I think. Added changelog entry for deprecations (not adding any functions yet). Thanks!

@kngwyu
Copy link
Member

kngwyu commented Dec 27, 2020

Thanks!

@kngwyu kngwyu merged commit 3f093d9 into PyO3:master Dec 27, 2020
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.

None yet

3 participants