`pyo3-macros-backend` is now compiled with PyO3 cfgs to enable different magic method definitions based on version.
Add check for correct number of arguments on magic methods.
* Add decorator example crate and split off chapter
* Move not-examples to their own folder
* Add some readme's
* Make black happy
* Make clippy happy
* Add decorator example crate and split off chapter
* Fix ci
* Add empty workspace key
* Try fix ci
* fix ci
* reuse target dir for examples CI
* add pytests folder to makefile recipes
* fix ci, try 2
* add missing pyproject.toml
* remove TOX_TESTENV_PASSENV from Makefile
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
This patch annotates the `__call__` method of `PyCounter` in example: callable
objects with `#[args(args="*", kwargs="**")]`. Without it (at least in PyO3
0.15.0) the example fails with `TypeError: counter.__call__() missing 1
required positional argument: 'args'`.
* Add support for positional-only args
* Update changelog. Add a few more tests. Run rust-fmt.
* Fix test.
* Fix tests again.
* Update CHANGELOG.md to link PR instead of issue
* Update guide to mention positional-only params
* Add unreachable!() per code review
* Update and expand tests for pos args.
* Fix tests, lint, add UI tests.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Add 'anyhow' feature which provides simple From<anyhow::Error> for PyErr impl
This makes it possible to use anyhow::Result<T> as the return type for
methods and functions exposed to Python.
The current implementation just stringifies the anyhow::Error before
shoving it into a PyRuntimeError. Conversion back to the anyhow::Error
is not possible, but it is better than nothing.
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
* Document `anyhow` feature in the guide
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
* update changelog to document anyhow feature
* WIP adding tests
* Finish up anyhow feature
* Fix formatting
* Fix tests
* Fix tests
* Apply review suggestions
Co-authored-by: Bruno Kolenbrander <59372212+mejrs@users.noreply.github.com>
Co-authored-by: mejrs <brunokolenbrander@hotmail.com>
* Clean up doctests, deny some lints
* Apply suggestions from review.
* replace \" with '
* Fix some more doc examples
* Fix formatting
* Fix some more things
* Remove unused parentheses
* Only test class sig on supported abi/platforms
* Only test class signature on correct versions
* Fix tests to compile on msrv
* msrv strikes yet again
* Add feedback
* Pin `half` to 1.7.1 on msrv
I have a use case in PyOxidizer where I want to use the
pyo3-build-config crate as a library crate so I can access the
`InterpreterConfig` struct so I can read/write config files without
reinventing the wheel.
This is doable before this commit. But it requires that the
build environment have a Python interpreter. This is undesirable
for library usage.
This commit introduces a cargo feature flag to control whether the
build script does anything. The feature flag must be present for
the build script to resolve a config. The feature flag is enabled
by default for backwards compatibility. The pyo3 and pyo3-macros-backend
crates use this feature by default, for backwards compatibility and
because it is the reasonable default.
This is probably room to conditionalize some APIs and other behavior
based on this feature flag. But we stop short of doing that for
the time being.
Jakub Kołodziejczak