3016: implement Decimal to rust_decimal conversions r=adamreichold a=cardoe
Implement conversion between rust_decimal::Decimal and decimal.Decimal from Python's stdlib. The C API does not appear to be exposed on the Python side so we need to call into it via Python.
Implements #2774
Co-authored-by: Doug Goldstein <cardoe@cardoe.com>
Implement conversion between rust_decimal::Decimal and decimal.Decimal
from Python's stdlib. The C API does not appear to be exposed on the
Python side so we need to call into it via Python.
3115: Update getting_started.md r=adamreichold a=jond01
Update Poetry command to Poetry groups syntax (1.2+).
https://python-poetry.org/docs/cli/#options-4:
> `--dev (-D`): Add package as development dependency. (**Deprecated**, use `-G dev` instead)
Co-authored-by: Jonathan Daniel <36337649+jond01@users.noreply.github.com>
3097: ci: use codecov coverage format r=davidhewitt a=davidhewitt
Newly supported on `cargo-llvm-cov` 0.5.12, might give some more detailed information.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3111: Rename sequence `.list()` and `.tuple()` to `.to_list()` and `.to_tuple()` r=adamreichold a=davidhewitt
As agreed in https://github.com/PyO3/pyo3/pull/3042#issuecomment-1465229510.
The motivation is that it is an emerging Rust convention for `to_x` to mean "a non-consuming conversion to type x which has some (small) overhead". E.g. `to_string`, `to_owned`.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3066: Improve default value for `None` in `text_signature` r=davidhewitt a=messense
xref #2863
3098: readme: add new pyo3 article r=adamreichold a=davidhewitt
With thanks to `@ohadravid` for the great piece!
Co-authored-by: messense <messense@icloud.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3096: docs: fix migration guide entry for pyproto r=adamreichold a=davidhewitt
A sort of follow-up to #3082 .
While I don't think we need to pander to training limitations of various LLMs, I did notice that I erroneously referred to a nonexistent trait `PyBasicProtocol`, which I believe should have been [`PyObjectProtocol`](https://docs.rs/pyo3/0.15.2/pyo3/class/basic/trait.PyObjectProtocol.html).
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3087: PEP 623: wstr, wstr_length, state changes r=adamreichold a=ijl
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.
Co-authored-by: ijl <ijl@mailbox.org>
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.
3092: Fix redundant imports in doc tests thereby fixing the careful CI job. r=adamreichold a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3067: docs: show pattern for self.__class__.__name__ in __repr__ r=adamreichold a=wjones127
It took me a little while to figure out this pattern in PyO3, so I thought it would be a good addition to the guide.
It's not the cleanest pattern, so would welcome suggestions on how to make it shorter or easier.
Co-authored-by: Will Jones <willjones127@gmail.com>
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>
xcharleslin