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

[internal] Inline some of externs/mod.rs and make GIL acquisition explicit #13522

Merged
merged 7 commits into from
Nov 8, 2021

Conversation

Eric-Arellano
Copy link
Contributor

A couple of refactors to simplify our rust-cpython FFI code.

Most notable is rewriting gettattr_as_string to be getattr_as_optional_string, which is always how it was behaving. That is, we used to tolerate if Python was set to str | None, even though most call sites expected str. This rename makes clear the difference.

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
This is more boilerplate, but makes clear at call sites that the GIL is held during Eq

# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
# Building wheels and fs_util will be skipped. Delete if not intended.
[ci skip-build-wheels]
Comment on lines +299 to 303
match externs::getattr_as_optional_string(py, value, "working_directory") {
None => None,
Some(dir) => Some(RelativePath::new(dir)?),
};

Copy link
Contributor

Choose a reason for hiding this comment

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

Just use .map(|s| RelativePath::new(s)?)

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 tried, but complains that the closure isn't returning Option or Result, so the ? doesn't work. The only way I could get things to compile is RelativePath::new().unwrap(), which is a downgrade from before

externs::getattr_as_string(&externs::getattr(value, "cache_scope").unwrap(), "name")
.try_into()?;
let cache_scope: ProcessCacheScope = {
let cache_scope_enum: PyObject = externs::getattr(value, "cache_scope").unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe avoid the unwrap? .ok_or_else(|| "Missing cache_scope attribute".into())?

Copy link
Contributor

Choose a reason for hiding this comment

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

Similar comment applies to other locations with .unwrap

Copy link
Contributor Author

@Eric-Arellano Eric-Arellano Nov 8, 2021

Choose a reason for hiding this comment

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

I think that might be even more confusing. Really, this should not be calling .unwrap() and should propagate the error. But error handling is clunky in rust-cpython (much better with PyO3). My main focus is getting PyO3 working with making as few changes as feasible. Then, once PyO3 lands, we can start improving the code like this.


let glob_match_error_behavior: PyObject =
externs::getattr(item, "glob_match_error_behavior").unwrap();
let failure_behavior = externs::getattr_as_string(&glob_match_error_behavior, "value");
let failure_behavior: String = externs::getattr(&glob_match_error_behavior, "value").unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

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

.ok_or_else(|| "Some message".into())?

@Eric-Arellano Eric-Arellano merged commit 30c304b into pantsbuild:main Nov 8, 2021
@Eric-Arellano Eric-Arellano deleted the rust-cpython-hasattr branch November 8, 2021 16:41
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.

2 participants