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.
Georg Brandl