correct ffi definition of PyIter_Check #2914
Conversation
2873: A new example that shows how to integrate Python plugins that use pyclasses into a Rust app r=davidhewitt a=alexpyattaev
Example showing integration of a Python plugin into a Rust app while having option to test pyclass based API without the main app. This also illustrates some aspects related to import of Python modules into a Rust app while also having an API module available for the Python code to be able to produce Rust objects.
CI seems to fail on my local machine for reasons unrelated to the example just added:
```
error: unused macro definition: `check_struct`
--> pyo3-ffi-check/src/main.rs:13:18
|
13 | macro_rules! check_struct {
| ^^^^^^^^^^^^
|
```
2889: Added support for PyErr_WriteUnraisable r=davidhewitt a=mitsuhiko
Fixes #2884
2923: hygiene: fix `#[pymethods(crate = "...")]` r=davidhewitt a=davidhewitt
Got to the bottom of the hygiene issue in test of #2914
Turns out that `#[pymethods] #[pyo3(crate = "...")]` works, but `#[pymethods(crate = "...")]` was ignoring the argument.
Added a tweak to fix this and a snippet in the hygiene test (which fails on `main`).
2924: remove unneeded into_iter calls r=davidhewitt a=davidhewitt
Clippy complaining about these to me this morning locally.
Co-authored-by: Alex Pyattaev <alex.pyattaev@gmail.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Armin Ronacher <armin.ronacher@active-4.com>
2923: hygiene: fix `#[pymethods(crate = "...")]` r=davidhewitt a=davidhewitt Got to the bottom of the hygiene issue in test of #2914 Turns out that `#[pymethods] #[pyo3(crate = "...")]` works, but `#[pymethods(crate = "...")]` was ignoring the argument. Added a tweak to fix this and a snippet in the hygiene test (which fails on `main`). 2924: remove unneeded into_iter calls r=davidhewitt a=davidhewitt Clippy complaining about these to me this morning locally. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
davidhewitt
force-pushed
the
fix-iter-check
branch
2 times, most recently
from
936bfec
to
b010c9d
Compare
|
Rebased & tests adjusted. |
davidhewitt
force-pushed
the
fix-iter-check
branch
from
b010c9d
to
d8e4737
Compare
|
@davidhewitt This (like all other PR) will fail the MSRV build due to trybuild bump MSRV (via basic-toml) in a point release. I think we need to pin it to 1.0.76... |
adamreichold
force-pushed
the
fix-iter-check
branch
from
d8e4737
to
117a433
Compare
I took the liberty of rebasing this onto the current |
|
Thanks! It would have been ok to just leave that to bors too :) bors r+ |
2914: correct ffi definition of PyIter_Check r=davidhewitt a=davidhewitt Closes #2913 It looks like what is happening is that PyO3 was relying on an outdated macro form of `PyIter_Check` which is now a CPython implementation detail, which would explain why it was behaving inconsistently on different platforms (likely due to differences in linkers / implementations). The test I've pushed succeeds, but fails to compile due to a hygiene bug! I'm done for tonight so I'll take a look at that soon and then rebase this after. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
|
Build failed: |
davidhewitt
force-pushed
the
fix-iter-check
branch
from
117a433
to
f495322
Compare
|
Looks like I fluffed the |
|
bors retry |
2914: correct ffi definition of PyIter_Check r=davidhewitt a=davidhewitt Closes #2913 It looks like what is happening is that PyO3 was relying on an outdated macro form of `PyIter_Check` which is now a CPython implementation detail, which would explain why it was behaving inconsistently on different platforms (likely due to differences in linkers / implementations). The test I've pushed succeeds, but fails to compile due to a hygiene bug! I'm done for tonight so I'll take a look at that soon and then rebase this after. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
|
Build failed: |
|
Hmm. It looks like this night have always been broken on Windows. We might just have to remove this functionality on Python 3.7 (which only has this broken macro form, the function form of |
|
I've pushed a commit which removes This is a bit unfortunate, but it's broken and I can't see a way to fix. I think this is better than the alternative of leaving this defined but broken on CPython 3.7 on Windows. I'd welcome feedback here, otherwise I'll merge this sometime ahead of the 0.18.1 release early next week. |
|
Is much prefer Otherwise we'd have to drop 3.7 support from pydantic v2, and I've promised to support all python versions that are still alive. "This thing is broken on windows on 3.7" is fine, but "we don't support 3.7" will annoy a lot of people. |
|
Why not do a |
|
According to https://pypistats.org/packages/pydantic 3.7 is still the second most common version with 25% of downloads.
|
Good idea - I'll change to that (and I'll use it in |
davidhewitt
force-pushed
the
fix-iter-check
branch
from
6b30a41
to
9094210
Compare
davidhewitt
force-pushed
the
fix-iter-check
branch
from
9094210
to
5bab0e9
Compare
|
Ok, that's pushed - let's see if it works on CI. |
|
bors try |
tryBuild succeeded: |
|
That's a success! Thanks all for reviews & design assistance here. bors r+ |
|
Build succeeded: |
Closes #2913
It looks like what is happening is that PyO3 was relying on an outdated macro form of
PyIter_Checkwhich is now a CPython implementation detail, which would explain why it was behaving inconsistently on different platforms (likely due to differences in linkers / implementations).The test I've pushed succeeds, but fails to compile due to a hygiene bug! I'm done for tonight so I'll take a look at that soon and then rebase this after.