implement PySequenceMethods

[davidhewitt]

For #3382

This moves the API for PySequence to be implemented by a pool-free implementation. As per the rest of the PRs, the new trait PySequenceMethods is restricted to pub(crate) for now while we're iterating on this.

[codspeed-hq]

CodSpeed Performance Report

Merging #3535 will not alter performance

_{Comparing davidhewitt:sequence2 (1583828) with main (d8a6f37)}

Summary

✅ 78 untouched benchmarks

[adamreichold]

Would it make sense to abstract out the repeating

Py2::from_owned_ptr_or_err(
    self.py(),
    f(self.as_ptr()),
)
.map(|py2| py2.downcast_into_unchecked())

using a for example a closure-based API with f: FnOnce(*mut PyObject) -> R?

[davidhewitt]

Yes, I think there could definitely be a pub(crate) helper to do this. I'll have a play 👍

[davidhewitt]

I've pushed a commit which adds Py2::do_ffi_call which has a generic return type with a bit of trait magic to map raw ffi return values into various safe wrappers. What do you think?

[davidhewitt]

Staring at this again I wonder if it should have been a safe trait with the method being unsafe fn from_ffi_call_result. Both are a bit awkward because only the implementation for *mut ffi::PyObject actually needs to be unsafe. Anyway, this is only an internal API so it doesn't need to be perfect...

[birkenfeld]

Reading the comment above, why does it have to be unsafe at all? "May get a pointer and do unsafe stuff with it" doesn't sound like a strong argument :)

[davidhewitt]

I'm generally of the understanding that the pointer alone can't communicate that's it's safe to read.

Probably the right approach is to combine this with some wrapper along the lines of #1809 so that the trait doesn't need to be unsafe at all. I'll keep playing.

[davidhewitt]

Closing in favour of #3572