* Remove use of unwrap
* Update changelog
* Update CHANGELOG.md
Co-authored-by: Mo Mirza <mo.mirza@iwoca.co.uk>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
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.
PyOxidizer has crates depending on `pyo3` that would like to access
the `pyo3` crate configuration. (This use case isn't unique to
PyOxidizer.)
Cargo has a facility for enabling the build scripts of dependent
crates to access _exported_ variables via `DEP_` environment
variables. However, this only works if the exporting crate defines a
`links` key in its Cargo manifest. See
https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key.
While `pyo3`'s build script doesn't yet export the variables that
PyOxidizer will need, a prerequisite to making this work is adding
the `links` key. Since this change could introduce unintended
side-effects, it warrants being made in its own commit, which is
why we're making this change outside of #1793.
I _think_ this change should be mostly safe: the `links` key is
effectively metadata advertising that a crate links against a named
library. The only side-effects setting it has is to enable the
aforementioned `DEP_` environment variables in build scripts and
enforcing a limitation that only a single crate may link against the
same native library. I believe the only potential for this change
to cause problems is if there are multiple crates with `links =
"python"` entries. I'm not aware of any other crates that advertise
`links = "python"`: even `python3-sys` / `cpython` use `links =
"python3"` so this change should not prevent dual use of `pyo3` and
`cpython` in the same build.
With the recent implementation of non-limited unicode APIs, we're
able to query Python's low-level state to access the raw bytes that
Python is using to store string objects.
This commit implements a safe Rust API for obtaining a view into
Python's internals and representing the raw bytes Python is using
to store strings.
Not only do we allow accessing what Python has stored internally,
but we also support coercing this data to a `Cow<str>`.
Closes#1776.
When building an extension with rust-numpy and ndarray on the MSRV of
1.41 with complex numbers. The num-complex crate version needs to be
0.2 which was the pinned version as of ndarray 0.13.1 which was the last
release of ndarray that supported building with rust 1.41. However, the
pyo3 pinned version of 0.4 is incompatible with this and will cause an
error when building because of the version mismatch. To fix this This
commit expands the supported versions for num-complex to match what
rust-numpy uses [1] so that we can build pyo3, numpy, ndarray, and
num-complex in an extension with rust 1.41.
Fixes#1798
[1] https://github.com/PyO3/rust-numpy/blob/v0.14.1/Cargo.toml#L19
The setter function will receive a NULL value on deletion requests.
This wasn't properly handled before, leading to a panic.
The new code raises AttributeError in this scenario instead.
A test for the behavior has been added. Documentation has also
been updated to reflect the behavior.
The field wasn't defined previously. And the enum wasn't defined as
`[repr(C)]`.
This missing field could result in memory corruption if a Rust-allocated
`PyStatus` was passed to a Python API, which could perform an
out-of-bounds write. In my code, the out-of-bounds write corrupted a
variable on the stack, leading to a segfault due to illegal memory
access. However, this crash only occurred on Rust 1.54! So I initially
mis-attribted it as a compiler bug / regression. It appears that a
low-level Rust change in 1.54.0 changed the LLVM IR in such a way to
cause LLVM optimization passes to produce sufficiently different
assembly code, tickling the crash. See
https://github.com/rust-lang/rust/issues/87947 if you want to see
the wild goose chase I went on in Rust / LLVM land to potentially
pin this on a compiler bug.
Lessen learned: Rust crashes are almost certainly due to use of
`unsafe`.
GILGuard::acquire() cannot be called during multi-phase Python
interpreter initialization because it calls Py_IsInitialized(),
which doesn't report the interpreter as initialized until all
phases of initialization have completed.
PyOxidizer uses the multi-phase initialization API and needs to
interact with pyo3's high-level APIs (not the FFI bindings) after
partial interpreter initialization, before the interpreter is fully
initialized. Attempts to use GILGuard::acquire() result in a panic
due to the aforementioned Py_IsInitialized() check failing.
This commit refactors the GILGuard logic into a function that
obtains the actual GILGuard and another function to perform
checks before calling the aforementioned functions.
A new unsafe `Python::with_gil_unchecked()` has been defined
to acquire the GIL via the unchecked code path so we may obtain
a `Python` during multi-phase initialization (and possibly other
scenarios).
* Add support to IndexMap
* Fix indexmap version to 1.6.2
* Remove code duplication by mistake
* Fix ambiguity in test
* Minor change for doc.rs
* Add to lib.rs docstring
* Add indexmap to conversion table
* Add indexmap flag in docs.rs action
* Add indexmap feature to CI
* Add note in changelog
* Use with_gil in tests
* Move code to src/conversions/indexmap.rs
* Add PR number to CHANGELOG
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Add round trip test
* Fix issue in MSRV Ubuntu build
* Fix Github workflow syntax
* Yet Another Attempt to Fix MSRV Ubuntu build
* Specify hashbrown to avoid ambiguity in CI
* Add suggestions
* More flexible version for indexmap
* Add documentation
* Address PR comments
* Export indexmap for docs
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
If we got more then one file, only take those that contain the arch name.
For ubuntu 20.04 with host architecture x86_64 and a foreign architecture of armhf
this reduces the number of candidates to 1:
$ find /usr/lib/python3.8/ -name '_sysconfigdata*.py' -not -lname '*'
/usr/lib/python3.8/_sysconfigdata__x86_64-linux-gnu.py
/usr/lib/python3.8/_sysconfigdata__arm-linux-gnueabihf.py
CHANGELOG.md: add entry for cross-sysconfigdata filter on arch
commit changelog:
1. initial
2. if filtered list is empty, use pre filtered.
3. clippy is_empty and cloned
The config header parsing code was supposed to be only invoked when
cross-compiling for Windows, but in reality it fails to correctly parse
the config header files shipped with the upstream Python for Windows.
Given that there are now better options for reliable cross-compiling
for Windows such as `PYO3_CROSS_PYTHON_VERSION` or the `abi3-py3*` features,
it should be OK to remove this config for v0.14.
Update the cross-compilation instructions section of the user guide.
Fixes https://github.com/PyO3/pyo3/issues/1337
While these are defined as macros in the Python C API, they rely on
access to the PyTypeObject structure, which is not part of the limited
API for those versions.
The DLL of the mingw Python in MSYS2 is named libpython3.8.dll:
$ python3 -m sysconfig | grep LIBPYTHON
LIBPYTHON = "-lpython3.8"
Add another special case to in get_rustc_link_lib() to handle that case.
Afaik the mingw build doesn't support the limited ABI, so skipt that as well.
This makes all tests pass in an MSYS2 environment and lets us build
python-cryptography.
After `extern { type ... }` has stabilized for a while, this can
be replaced. For now, I used a macro since it is much easier to
spot the locations to touch at that time.
fixes#1311
This is a useful API in long-running Rust code, which lets users
cancel evaluation by pressing Ctrl-C, and run any other signal
handlers that have been set using the signal module.
* Fix compilation on platforms that don't use i8 for c_char
This commit changes the cast of an c_char to be a c_char type instead of
i8. On x86 platforms i8 == c_char, but it can also be u8 on other
platforms. [1][2] This should fix compilation on those platforms by just
using the c_char type so that we're casting as the right type regardless
of which platform PyO3 is being built for.
Fixes#1181
[1] https://doc.rust-lang.org/std/os/raw/type.c_char.html
[2] https://github.com/rust-lang/rust/blob/master/library/std/src/os/raw/mod.rs#L55-L99
* Add changelog entry
* Added a couple basic tests
* Implemented suggested change
* Fixed type inference
* cargo fmt
* Finished tests and removed warnings
* Include in CHANGELOG.md
* Moved test into separate file
* &'static str and function rename
* Mention in the book
* Add (failing) tests for issue #1064
* Return NotImplemented when richcmp doesn't match the expected type.
* Fix tests that expect TypeError when richcmp returns NotImplemented.
- The python code 'class Other: pass; c2 {} Other()' was raising a NameError:
c2 not found
- eq and ne never raise a TypeError, so I split the those cases.
* Return NotImplemented for number-like binary operations.
* Add dummy impl PyNumberProtocol for the test struct.
* Rework tests of NotImplemented.
* Make py_ternary_num_func return NotImplemented when type mismatches.
* Return NotImplement for type mismatches in binary inplace operators.
* Reduce boilerplate with `extract_or_return_not_implemented!`
* Extract common definition 'Other' into a function.
* Test explicitly for NotImplemented in the __ipow__ test.
* Add entry in CHANGELOG for PR #1072.
* Add the section 'Emulating numeric types' to the guide.
* Ensure we're returning NotImplemented in tests.
* Simplify the tests: only test we return NotImplemented.
Our previous test were rather indirect: were relying that Python
behaves correctly when we return NotImplemented.
Now we only test that calling a pyclass dunder method returns NotImplemented
when the argument doesn't match the type signature. This is the expected
behavior.
* Remove reverse operators in tests of NotImplemented
The won't be used because of #844.
* Apply suggestions from code review
Co-authored-by: Yuji Kanagawa <yuji.kngw.80s.revive@gmail.com>
* Add a note about #844 below the list of reflected operations.
Co-authored-by: Yuji Kanagawa <yuji.kngw.80s.revive@gmail.com>
* Added Rust initialisation of Python-allocated bytes
* Added unsafe PyBytes::new_with_unit constructor
* Added examples to PyBytes::new_with and PyBytes::new_with_uninit (now with MaybeUninit<u8>)
* Fixed doc test imports for PyBytes::new_with and PyBytes::new_with_uninit
* Fixed clippy error in PyBytes::new_with_uninit test
* Added PyByteArray::new_with and Removed PyBytes::new_with_uninit
* Small doc fixes + FnOnce init closure for PyBytes::new_with and PyByteArray::new_with
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Fixed where clause formatting in PyBytes::new_with and PyByteArray::new_with
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
David Hewitt