* #[pymodule] mod some_module { ... } v3
Based on #2367 and #3294
Allows to export classes, native classes, functions and submodules and provide an init function
See test/test_module.rs for an example
Future work:
- update examples, README and guide
- investigate having #[pyclass] and #[pyfunction] directly in the #[pymodule]
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
Co-authored-by: Georg Brandl <georg@python.org>
* tests: group exported imports
* Consolidate pymodule macro code to avoid duplicates
* Makes pymodule_init take Bound<'_, PyModule>
* Renames #[pyo3] to #[pymodule_export]
* Gates #[pymodule] mod behind the experimental-declarative-modules feature
* Properly fails on functions inside of declarative modules
---------
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
Co-authored-by: Georg Brandl <georg@python.org>
* fix `either` feature conditional compilation, again
* test feature powerset in CI
* install `rust-src` for feature powerset tests
* review: adamreichold feedback
* Fix one more case of redundant imports.
* just check feature powerset for now
---------
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
I chose to make the dependency mandatory instead of optional as portable-atomic
itself just forwards to the native atomics when they are available so making
that choice part of our build system is not really necessary. Personally, I was
unable to perceive any noticeable compile-time hit from adding it.
3211: Enable v2 resolver on the workspace to enable dropping PYO3_CI workaround r=davidhewitt a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
While the xtask code base is better engineered than our slightly messy Nox
manifest, all functionality is available via Nox including some that is not
available via xtask. Finally, only the Nox sessions are used in the CI by now so
that xtask does not see regular automated usage.
3209: Remove the conditional compilation flags which are made redundant by the MSRV bump r=davidhewitt a=adamreichold
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3203: support ordering magic methods for `#[pyclass]` r=adamreichold a=davidhewitt
Closes#2089
This adds `__lt__`, `__le__`, `__eq__`, `__ne__`, `__gt__`, and `__ge__` as per the Python implementations of what we call `__richcmp__`.
There's a UI test confirming that the user cannot implement split forms and `__richcmp__` simultaneously.
There's also a benchmark comparing implementing these split methods against using `__richcmp__`. I couldn't see a meaningful performance difference, so I'm tempted to deprecate `__richcmp__`, given that's not a magic method which exists in Python. Potentially we can provide options such as the opt-in `#[pyclass(eq, ord)]` to avoid boilerplate for people who don't want to implement six different methods.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
David Hewitt