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>
2975: RFC: Add GILProtected synchronization primitive and use it for LazyTypeObjectInner. r=davidhewitt a=adamreichold
I would also like to use that type in rust-numpy and it seems we can avoid ~~both a manual unsafe impl and~~ a full blown mutex if we apply it to `LazyTypeObjectInner`.
One downside might be that it ties us closer to the GIL when we want to enable nogil experimentation, but on the other hand, it may also help by reifying the GIL usage. (This is currently limited to comments in unsafe code in rust-numpy for example.)
3022: Fix function name shadowing r=davidhewitt a=mejrs
Fixes https://github.com/PyO3/pyo3/issues/3017
3023: Emit a better error for bad argument names r=davidhewitt a=mejrs
This will emit a better error for code like
```rust
#[pyfunction]
fn output([a,b,c]: [u8;3]) {}
```
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Co-authored-by: mejrs <59372212+mejrs@users.noreply.github.com>
3055: Fix compile error when trying to use static slot methods, fixes: #3039 r=davidhewitt a=willstott101
Whilst having static slot methods is of dubious value in the first place, there's little reason not to support it by bringing the different function call macros more in-line with each other.
I had no idea which test file to use so I just made a new one... `test_methods.rs` has no slots in and the test files that do use slots seem to be specific to their protocol. Let me know if you'd like the test somewhere else.
Thanks!
Co-authored-by: Will Stott <willstott101@gmail.com>
3044: Add `PyTuple::to_list` r=davidhewitt a=davidhewitt
Companion to #3043. I've included benchmarks which suggests that this method is indeed about 25% faster on my machine.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3056: ci: pin syn to 1.0 for MSRV r=davidhewitt a=davidhewitt
Looks like syn 2.0 requires Rust 1.56 - it'll be interesting for us to update to this one day, but not quite yet!
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3049: Add Blog post in Articles and other media section r=messense a=AdilZouitine
Hi there 👋,
This pull request adds a link to a blog post in the PyO3 README under the "Articles and other media" section. The blog post, titled "How we extended the River stats module with Rust using PyO3," details our experience in utilizing PyO3 to improve the performance of the River library's stats module.
Co-authored-by: Adil Zouitine <adilzouitinegm@gmail.com>
3043: `PyList::as_tuple()` -> `PyList::to_tuple()` r=mejrs a=davidhewitt
As discussed as a follow-up to #3042
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3042: add `as_tuple()` method to `PyList` r=davidhewitt a=samuelcolvin
From [benchmarks](25fcf98e12/benches/main.rs (L165-L192)), this is significantly faster than `PyTuple::new(py, the_list)`:
```
test list_as_tuple_direct ... bench: 299 ns/iter (+/- 51)
test list_as_tuple_iterate ... bench: 521 ns/iter (+/- 41)
```
Co-authored-by: Samuel Colvin <s@muelcolvin.com>
3036: fix const-ness of some FFI name & doc members r=adamreichold a=davidhewitt
I just noticed that these are [`*const` since Python 3.7](007d7ff73f (diff-830b405713d1c40982ffa918864e39c40c1b318d79b8dd2b523646dc3bd18b52)).
This might break existing compiles, so will not include this in 0.18.2.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3031: mangle exported functions for PyPy r=davidhewitt a=mattip
I run HEAD of PyO3 with HEAD of some PyPy branches, and noticed that the py3.10 branch (which implements python3.10) [fails to properly build](https://github.com/pypy/binary-testing/actions/runs/4334873617/jobs/7569059852#step:6:179). The failure was a missing export:
```
/home/runner/work/binary-testing/binary-testing/pyo3/src/exceptions.rs:715: \
undefined reference to `PyExc_EncodingWarning'
collect2: error: ld returned 1 exit status
```
So I grepped around in the code for `Py_3_10` to see what new functions were added and found a few that needed PyPy-specific exports.
Co-authored-by: Matti Picus <matti.picus@gmail.com>
3014: feat: add #[pyo3(get, set)] for Cell r=davidhewitt a=AntoineRR
This fixes#2659.
The types for which `#[pyo3(get, set)]` should now work are `Cell`, `Arc` and `Box`.
There is one issue regarding `Box`, the implementation of `FromPyObject` conflicts with another one. I could not find what the issue was, especially since the other implementations for `Arc` and `Cell` work as expected. The related code and test has been commented out for now. Maybe someone could help me fix this issue if I don't figure it out myself? There is also the possibility to remove the implementation for `Box` of course.
Co-authored-by: Antoine Romero-Romero <ant.romero2@orange.fr>
3032: fix clippy and ui tests for Rust 1.68 r=adamreichold a=davidhewitt
The usual 😄
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3019: Use stable toolchain for Valgrind job as version 3.20 should handle the DWARF version. r=adamreichold a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3009: Remove stale references to tox.ini from template substitution scripts. r=messense a=adamreichold
Closes#3008
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2993: fix `non_snake_case` lint for `#[pyfunction]` generated code r=davidhewitt a=davidhewitt
As promised in #2990
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
messense