https://peps.python.org/pep-0623/
Following members are removed from the Unicode structures:
wstr
wstr_length
state.compact
state.ready
Note state.compact is still present as of v3.12.0a7.
state.interned has changed width from 2 to 1 bits.
3015: Implement wrapper for `PyASCIIObject.state` bitfield accesses r=davidhewitt a=decathorpe
This is a first draft of my attempt to fix#1824 "properly" by writing a C wrapper for the `PyASCIIObject.state` bitfield accesses, as proposed here: https://github.com/PyO3/pyo3/issues/1824#issuecomment-1406909504
---
The original argument for making these functions `unsafe` is still valid, though - bitfield memory layout is not guaranteed to be stable across different C compilers, as it is "implementation defined" in the C standard. However, short of having CPython upstream provide non-inlined public functions to access this bitfield, this is the next best thing, as far as I can tell.
I've removed the `#[cfg(target_endian = "little")]` attributes from all things that are un-blocked by fixing this issue on big-endian systems, except for three tests, which look like expected failures considering that they do not take bit/byte order into account (for example, when writing to the bitfield).
- `ffi::tests::ascii_object_bitfield`
- `types::string::tests::test_string_data_ucs2_invalid`
- `types::string::tests::test_string_data_ucs4_invalid`
All other tests now pass on both little-endian and big-endian systems.
---
I am aware that some parts of this PR are probably not in a state that's acceptable for merging as-is, which is why I'm filing this as a draft. Feedback about how to better integrate this change with pyo3-ffi would be great. :)
In particular, I'm unsure whether the `#include` statements in the C files are actually correct across different systems. I have only tested this on Fedora Linux so far.
I'm also open to changing the names of the C functions that are implemented in the wrapper. For now I chose the most obvious names that shouldn't cause collisions with other symbols.
Co-authored-by: Fabio Valentini <decathorpe@gmail.com>
2843: remove functionality deprecated in 0.16 r=davidhewitt a=davidhewitt
Simple cleanup to remove all functionality marked deprecated in the 0.16 releases.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2838: pypy: re-enable PyFunction on 3.8+ r=davidhewitt a=davidhewitt
PyPy [fixed the crashes associated with `PyFunction](https://foss.heptapod.net/pypy/pypy/-/issues/3776#note_191626) in PyPy 7.3.10 (for 3.8+) - which I think is to be released shortly. So I think we should re-enable this API and treat it as a PyPy bug which users can mitigate by updating their PyPy.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
This appears to be the only way to chain exceptions via the FFI. It
was introduced prior to CPython 3.7. It has some description of usage
in PEP 490. There was a discussion of whether it should be made stable
in BPO 44938.
* Add FFI definitions for `Py_EnterRecursiveCall` and
`Py_LeaveRecursiveCall`
* Update pyo3-ffi/src/ceval.rs
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Fix PyObject_CallNoArgs python version cfg
PyObject_CallNoArgs was added to python 3.9 but not to limited api until 3.10 per https://docs.python.org/3/c-api/call.html#c.PyObject_CallNoArgs
* Update change log
* Fix uses of PyObject_CallNoArgs
Co-authored-by: Andrew Burkett <andrew.burkett@crowdstrike.com>
