-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release: 0.22.3 #4518
release: 0.22.3 #4518
Conversation
…4349) * Improve error messages for #[pyfunction] defined inside #[pymethods] Make error message more specific when `#[pyfunction]` is used in `#[pymethods]`. Effectively, this replaces the error message: ``` error: static method needs #[staticmethod] attribute ``` To: ``` functions inside #[pymethods] do not need to be annotated with #[pyfunction] ``` ...and also removes the other misleading error messages to the function in question. Fixes #4340 Co-authored-by: László Vaskó <1771332+vlaci@users.noreply.github.com> * review fixes --------- Co-authored-by: László Vaskó <1771332+vlaci@users.noreply.github.com>
* Update dict.get_item binding to use PyDict_GetItemRef Refs #4265 * test: add test for dict.get_item error path * test: add test for dict.get_item error path * test: add test for dict.get_item error path * fix: fix logic error in dict.get_item bindings * update: apply david's review suggestions for dict.get_item bindings * update: create ffi::compat to store compatibility shims * update: move PyDict_GetItemRef bindings to spot in order from dictobject.h * build: fix build warning with --no-default-features * doc: expand release note fragments * fix: fix clippy warnings * respond to review comments * Apply suggestion from @mejrs * refactor so cfg is applied to functions * properly set cfgs * fix clippy lints * Apply @davidhewitt's suggestion * deal with upstream deprecation of new_bound
* fix: updated pyclass heighten check to validate for eq and ord, fixing Ok issue in eq implementation. identified similar issues in Complex enum and tuple enum, resolved serveral cases, but working on current error coming from traits not being in scope * fix: fully qualified clone and from calls for enums. * update: added changelog entry --------- Co-authored-by: MG <mg@rookie.ninja>
#4382) * fix incorrect spans on `ret` and `py` local varianbles in emitted code * add newsfragment
Fixes #4400 As the return value is ultimately communicated back via a StopIteration exception instance, a peculiar behavior of `PyErr::new` is encountered here: when the argument is a tuple `arg`, it is used to construct the exception as if calling from Python `Exception(*arg)` and not `Exception(arg)` like for every other type of argument. This comes from from CPython's `PyErr_SetObject` which ultimately calls `_PyErr_CreateException` where the "culprit" is found here: https://github.com/python/cpython/blob/main/Python/errors.c#L33 We can fix this particular bug in the invocation of `PyErr::new` but it is a more general question if we want to keep reflecting this somewhat surprising CPython behavior, or create a better API, introducing a breaking change.
* Add PyList_GetItemRef bindings and compat shim * Use PyList_GetItemRef in list.get_item() * add release notes * apply code review comments * Update newsfragments/4410.added.md Co-authored-by: David Hewitt <mail@davidhewitt.dev> * apply `all()` doc cfg hints --------- Co-authored-by: David Hewitt <mail@davidhewitt.dev>
From now you cannot initialize a `PyClassInitializer<SubClass>` with `PyClassInitializer::from(Py<BaseClass>).add_subclass(SubClass)`. This was out of bounds write. Now it panics. See details at #4452.
* ffi: define compat for `Py_NewRef` and `Py_XNewRef` * add missing inline hint Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com> * don't use std::ffi::c_int (requires MSRV 1.64) * add test to guard against ambiguity * fix `Py_NewRef` cfg on PyPy --------- Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
* Use vectorcall (where possible) when calling Python functions This works without any changes to user code. The way it works is by creating a methods on `IntoPy` to call functions, and specializing them for tuples. This currently supports only non-kwargs for methods, and kwargs with somewhat slow approach (converting from PyDict) for functions. This can be improved, but that will require additional API. We may consider adding more impls IntoPy<Py<PyTuple>> that specialize (for example, for arrays and `Vec`), but this i a good start. * Add vectorcall benchmarks * Fix Clippy (elide a lifetime) --------- Co-authored-by: David Hewitt <mail@davidhewitt.dev>
ec0276f
to
5abc496
Compare
…4462) * ci: swap .python-version file for explicit versions in actions yml * pin valgrind job to 3.12.4
|
* ci: fix nightly warning about unreachable pattern * add comment
371593b
to
d8510d1
Compare
Ok, with CI now green I've pushed a release commit with a suggested release date of the 15th (Sunday). There is a very minor breaking change in the removal of I delayed similar removals of If I hear no reason to delay, will put this live on Sunday! |
Will release this now. |
I think we've accumulated a lot of fixes (and a whole lot of non-breaking improvements) which would be good to release, and it seems we're still a little way away from 0.23.
So I'll start preparing this branch for release and hope to put this live soon once we have a passing CI.