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>
* Expand on the C api
* Fix Ci
* Fix PyCodeObject structure
* Add descrobjects
* Add None and NotImplemented type objects
* Update pyo3-ffi/src/cpython/object.rs
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Fix PyPy definitions
* Fix CI
* Fix CI
* Fix CI
* Fix CI
* Fix CI
* Fix CI
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
This field was added in 3.10 but we missed it. This was causing
offsets of subsequent fields to be wrong. This could lead to
unexpected behavior or even crashes.
Add a new public crate function `cross_compile_from_to()` using
`target_lexicon::Triple` arguments instead of plain strings
used in `cross_compile()`.
Deprecate `pyo3_build_config::cross_compile()` since v0.17.
Attempt to extract common code patterns into methods and standalone
helper functions. Add docstrings to the new private items.
Make some of the new helper functions public within the PyO3 crate
and reuse them in the build scripts.
Add PYO3_CROSS_PYTHON_VERSION parsing unit test.
Add a ChangeLog entry mentioning the new `pyo3-build-config` API.
Instead of a fake build dependency, move the links key from pyo3 to pyo3-ffi
which according to [1] is a prerequisite for build scripts to emit meta-data
that can be used by other build scripts which would incidentally ensure the
ordering between the build script of pyo3 and pyo3-ffi that we need.
[1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#using-another-sys-crate
Adam Reichold