This is a compromise solution: we require the GIL to be held when acquiring
the slice, but not later when using the slice.
We could bind the lifetime of the returned slice to the Python-token lifetime
to prevent accessing the slice when the GIL is not held, but that causes
problems with the FromPyObject impl.
Alternatively we could not require the GIL at all when accessing the PyTuple
(and thus keep the ops::Index and IntoIterator implementations), but that
relies on too many CPython implementation details for my taste.
* FromPyObject for all conversions that don't need to borrow temporaries
* RefFromPyObject for extracting references out of temporaries
(currently only used for extracting `&str`)
Since the `Python` token no longer is a part of `PyObject`,
lots of methods now require the token as additional argument.
This [breaking-change] breaks everything!
This is a [breaking-change] and makes the trait more difficult to implement.
The usage through PyObject::extract() is unchanged.
This change allows extracting a `&str` through a temporary `Cow<str>`
without having to copy the string data from python to rust
(at least in cases where the python string is UTF-8 encoded).
This is preparation in hope I'll be able to make py_fn!()
automatically extract the function arguments.
This allows implementing `FromPyObject` for `Vec<T>`.
It also means that `obj.extract::<Cow<str>>()` won't be supported, but we
have `PyString::extract()` for that now.
replace PyPtr<'p, PyObject<'p>> with PyObject<'p>
Borrowed python pointers stay &PyObject<'p>.
Note: this means the internal representation of borrowed python pointers
changes from "*mut PyObject" to "&*mut PyObject".
Daniel Grunwald