-
Notifications
You must be signed in to change notification settings - Fork 782
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
add PyString::new_bound
#3774
add PyString::new_bound
#3774
Conversation
ddc7769
to
b399737
Compare
Sorry for the force-pushes here; I'll try to make the next one I push a bit tidier on first push... 🤦 |
CodSpeed Performance ReportMerging #3774 will degrade performances by 29.03%Comparing Summary
Benchmarks breakdown
|
@@ -206,7 +206,7 @@ impl PyErr { | |||
/// assert_eq!(err.to_string(), "TypeError: "); | |||
/// | |||
/// // Case #3: Invalid exception value | |||
/// let err = PyErr::from_value(PyString::new(py, "foo").into()); | |||
/// let err = PyErr::from_value(PyString::new_bound(py, "foo").as_gil_ref()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will have to wait for the corresponding PyErr
change, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we need to add PyErr::from_value_bound
I think.
(or add a trait which abstracts over &PyAny
and &Bound<PyAny>
just temporarily to ease migration, thought that'd be a new design question and less mechanical.)
b399737
to
c475656
Compare
Part of #3684
This implements
PyString::new_bound
and deprecatesPyString::new
as per the established pattern, updating internal code.There are other constructors on
PyString
, particularlyPyString::intern
, which I will cover in a separate PR to keep the diff smaller.