profile
viewpoint
David Hewitt davidhewitt @reinfer Oxford, UK https://www.linkedin.com/in/david-hewitt-4a393775/ Addicted to Rust. Full-stack developer; other than Rust you'll find me using Python, Vue.js and C++.

davidhewitt/password-check 2

A simple pwned password checker in Rust.

davidhewitt/scalajs-gradle-plugin 2

A planned gradle plugin to use the scalajs compiler.

davidhewitt/mio-anonymous-pipes 1

mio::Evented wrapper for windows anonymous pipes

davidhewitt/alacritty 0

A cross-platform, GPU-accelerated terminal emulator

davidhewitt/atom-vue 0

Vue component file syntax for Atom

davidhewitt/dwrote-rs 0

DirectWrite bindings and wrapper for Rust

davidhewitt/fastuuid 0

FastUUID is a library which provides CPython bindings to Rust's UUID library

issue commentPyO3/pyo3

Unable to specify keyword-only arguments

Sounds good

Is there also any code validating the parameters when calling a function ?

I think you're looking for parse_fn_args

sunjay

comment created time in 9 hours

issue commentPyO3/pyo3

Unable to specify keyword-only arguments

@dvermd please do! I'm happy to answer any questions and review your PR 👍

sunjay

comment created time in 11 hours

issue commentserde-rs/serde

Consider supporting concat! macro in attributes

(Repeating what I said in #1895)

Related: #450 (which is asking for #[serde(rename = SOME_CONST)], which I think has similar technical constraints).

dtolnay

comment created time in a day

pull request commentPyO3/setuptools-rust

Enable building abi3 shared objects

If you're willing to build that, would be great! (I was thinking I can take a stab eventually, though I'm still pretty worn out / chasing other chores from having moved house last week...)

alex

comment created time in 3 days

pull request commentPyO3/setuptools-rust

Enable building abi3 shared objects

:thumbsup: sounds like we can achieve that by adding a new CI job which installs maybe Python 3.6 and 3.8 and does exactly as you say. Probably doesn't need any new example code in that case.

alex

comment created time in 3 days

issue commentserde-rs/serde

Can't use stringify! in place of serde(rename = ...) and similar

Related: #450 (which is asking for #[serde(rename = SOME_CONST)], which I think has similar technical constraints).

Mingun

comment created time in 3 days

issue commentserde-rs/serde

Allow rename of container with &'static str

A note for those interested in this issue: I believe that the attribute syntax technical limitation no longer applies, so I took a look this morning into how hard it would be for serde to allow attributes like #[serde(rename = SOME_CONST)].

From what I could tell, it wouldn't be too hard to change the rename attribute argument to parse into an enum which is either a syn::LitStr or syn::Ident. But the challenge after that is that the downstream code in the derive macros is built on the fact these attributes are currently literal strings. For example the macros check the serialized field names do not conflict with the variant tag field name, which becomes impossible to do if the name is some transparent ident instead of a literal passed to the macro.

Perhaps if const assertions were a thing, the macro could emit compile-time assertions as part of the #[derive(Serialize)] impl and let the compiler resolve whether the field name and the tag name are the same. But that's a future 🚀 Rust feature.

SuperFluffy

comment created time in 3 days

issue commentPyO3/pyo3

Support all receiver types for all protocol methods

I think I see a way to make a PyMethodReceiver trait which is implemented by all five types.

davidhewitt

comment created time in 4 days

issue commentPyO3/pyo3

Trouble using PyContextProtocol

I think what I have in mind is non-breaking and not too hard so I can do over the weekend and we can potentially even release in a 0.12.2.

jothan

comment created time in 4 days

pull request commentPyO3/pyo3

Update paste requirement from 0.1.6 to 1.0.1

Oh haha good point! Let's merge this then as it doesn't seem to need an MSRV bump after all?

dependabot[bot]

comment created time in 4 days

pull request commentPyO3/pyo3

Update paste requirement from 0.1.6 to 1.0.1

This (and updating indoc) is blocked on an MSRV update to Rust 1.45. I don't think we're yet ready to consider it (RHEL doesn't appear to have released support yet), so marking this as blocked for now.

dependabot[bot]

comment created time in 5 days

Pull request review commentPyO3/setuptools-rust

Enable building abi3 shared objects

 def build_extension(self, ext):                  ext.install_script(ext_path)             else:-                ext_path = build_ext.get_ext_fullpath(target_fname)+                # Technically it's supposed to contain a+                # `setuptools.Extension`, but in practice the only attribute it+                # checks is `ext.py_limited_api`.+                build_ext.ext_map[ext.name] = ext+                try:+                    ext_path = build_ext.get_ext_fullpath(target_fname)+                finally:+                    del build_ext.ext_map[ext.name]

Actually maybe worth adding assert ext.name not in build_ext.ext_map before we start fiddling with this?

alex

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentPyO3/setuptools-rust

Enable building abi3 shared objects

 def build_extension(self, ext):                  ext.install_script(ext_path)             else:-                ext_path = build_ext.get_ext_fullpath(target_fname)+                # Technically it's supposed to contain a+                # `setuptools.Extension`, but in practice the only attribute it+                # checks is `ext.py_limited_api`.+                build_ext.ext_map[ext.name] = ext+                try:+                    ext_path = build_ext.get_ext_fullpath(target_fname)+                finally:+                    del build_ext.ext_map[ext.name]

Sneaky but I think that's fine to me ;)

alex

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentPyO3/setuptools-rust

Enable building abi3 shared objects

 class RustExtension:       optional : bool         if it is true, a build failure in the extension will not abort the         build process, but instead simply not install the failing extension.+      py_limited_api : bool+        Same as `py_limited_api` on `setuptools.Extension`. Note that if you+        set this to True, your extension must pass the appropriate feature+        flags to pyo3 (ensuring that `abi3` feature is enabled).

I'd like to wait to merge because there was talk of renaming the abi3 feature in pyo3. (Usually features should add to the lib, rather than abi3 which currently takes things away.)

alex

comment created time in 5 days

PullRequestReviewEvent

issue commentPyO3/pyo3

Add way to set metaclass for #[pyclass]

Any progress would have been on this issue! A proposal of how the API should look and / or a PR to implement this is always welcome 😄

programmerjake

comment created time in 5 days

issue commentPyO3/pyo3

Specifying the minimum supported python version

We already have #[cfg(Py_3_7)] or so for that purpose.

#[cfg(Py_3_7)] etc. only works inside of the pyo3 code though; downstream crates don't see these flags unless we give them a way to add them in their own build scripts.

konstin

comment created time in 5 days

issue commentPyO3/pyo3

Trouble using PyContextProtocol

Thanks, yes this is sadly a flaw with the #[pyproto] design at the moment which I've been aware of for a while but not found the right moment to fix. Perhaps this is now a good time. I've opened #1206 and will try to take a spin at this soon.

jothan

comment created time in 5 days

issue openedPyO3/pyo3

Support all receiver types for all protocol methods

At the moment the protocol methods are in an inconsistent state: some of them can take PyRef or PyRefMut, and some of them take &self or &mut self.

This is confusing to users and also gets in the way in certain cases like needing to access Python inside a protocol method (which can be obtained from PyRef::py() for example) or wanting to return PyRef<Self>.

The simple solution is to just change all protocol methods to use TryFromPyCell trait. This is however a breaking change.

The better solution is to change all #[pyproto] methods to support any of the five of &PyCell, PyRef<Self>, PyRefMut<Self>, &self and &mut self, just like we support for #[pymethods].

I've had some ideas how to approach this second point so would like to take a shot at it soon.

created time in 5 days

issue commentPyO3/pyo3

Conversion of non &[u8] slices as return types

I've been thinking about this too. I agree it'd be very nice to have full slice support.

I think that it could be hard to achieve this without either waiting for specialization to be stable (I think we might only need min_specialization in this case; not sure), or removing the &[u8] -> PyBytes special case.

impl<'a, 'b> IntoPy<&'b PyBytes> for &'a [u8] won't help, because really the only useful implementation of IntoPy is IntoPy<PyObject> which all our callback.rs utility code uses to convert Rust types to Python.

sebpuetz

comment created time in 5 days

push eventPyO3/pyo3

Sebastian Pütz

commit sha 0a346dfa7cb45ebc04aec54e2168699f3ad84bee

Add documentation for raw_pycfuntion

view details

David Hewitt

commit sha 0ec10a244978c3b09731ea1f66f301789a678715

Merge pull request #1174 from sebpuetz/raw-pycfun-docs Add documentation for raw_pycfuntion

view details

push time in 9 days

PR merged PyO3/pyo3

Reviewers
Add documentation for raw_pycfuntion

This adds instructions on how to use the raw_pycfunction!() macro to the guide. I forgot to include this in #1163.

It doesn't touch any .rs file, so this could probably be merged post release, too.

+52 -3

3 comments

3 changed files

sebpuetz

pr closed time in 9 days

pull request commentPyO3/pyo3

Add documentation for raw_pycfuntion

Thanks!

sebpuetz

comment created time in 9 days

push eventPyO3/pyo3

David Hewitt

commit sha fcf1d0ca9a153272f42f9bbdf906243b42672902

Tidy up guide release

view details

David Hewitt

commit sha 00440a79a1a19e2917e1c626484803043d1fd9de

Merge pull request #1199 from PyO3/davidhewitt-patch-6 Tidy up guide release

view details

push time in 11 days

PR merged PyO3/pyo3

Tidy up guide release

The changes from #1198 worked nicely, but the process is a bit messy. It currently runs three times and also doesn't have the version number in the commit that gets pushed to github pages.

This PR just tidies up those loose ends for when the next release happens.

+2 -1

2 comments

1 changed file

davidhewitt

pr closed time in 11 days

pull request commentPyO3/pyo3

Tidy up guide release

Yep exactly 😊

davidhewitt

comment created time in 11 days

push eventPyO3/setuptools-rust

David Hewitt

commit sha 007a3ede7d7f1eb28432f235de240f92c70e2ffc

Use Github Actions instead of Travis

view details

David Hewitt

commit sha 9fcd0e748e1ff8894c59e012e0f5b3642994a024

Merge pull request #78 from davidhewitt/github-actions Use Github Actions instead of Travis

view details

push time in 11 days

PR merged PyO3/setuptools-rust

Use Github Actions instead of Travis blocked

This is a follow-up to #77 which adds testing (by migrating to github actions).

This isn't ready to merge; on the way I found that I had to build a custom pyo3 branch to fix PyPy support.

I also had to fixup a few pieces of the setuptools-rust examples to behave better cross-platform!

+241 -217

7 comments

17 changed files

davidhewitt

pr closed time in 11 days

pull request commentPyO3/setuptools-rust

Use Github Actions instead of Travis

PyO3 0.12 released and working nicely here!

davidhewitt

comment created time in 11 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha 007a3ede7d7f1eb28432f235de240f92c70e2ffc

Use Github Actions instead of Travis

view details

push time in 11 days

PR opened PyO3/pyo3

Tidy up guide release

The changes from #1198 worked nicely, but the process is a bit messy. It currently runs three times and also doesn't have the version number in the commit that gets pushed to github pages.

This PR just tidies up those loose ends for when the next release happens.

+2 -1

0 comment

1 changed file

pr created time in 11 days

create barnchPyO3/pyo3

branch : davidhewitt-patch-6

created branch time in 11 days

push eventPyO3/pyo3

David Hewitt

commit sha c05815520cc58db2a3fb2f79b3379ac043676e11

Release 0.12.1

view details

David Hewitt

commit sha 15587f1b58db6891caa7a268a61aaf0fe84ca6f1

Merge pull request #1191 from PyO3/release-0.12.1 Release 0.12.1

view details

push time in 11 days

PR merged PyO3/pyo3

Release 0.12.1

There's been a couple of bugfixes to 0.12 which I think warrant a patch release before we start merging any new / breaking changes on the way to 0.13.

I'd like to publish this tomorrow evening (16th Sep). We can always make further patch releases if necessary (hopefully not).

I think it would be nice if a bugfix for #1185 was also included in this release. @kngwyu, I'm not sure if you're already working on one, I'll have a go at writing a fix tomorrow evening if I don't hear a reason not to.

+14 -15

1 comment

6 changed files

davidhewitt

pr closed time in 11 days

created tagPyO3/pyo3

tagv0.12.1

Rust bindings for the Python interpreter

created time in 11 days

release PyO3/pyo3

v0.12.1

released time in 11 days

push eventPyO3/pyo3

David Hewitt

commit sha 07f9ae2498fdd1906f676e3e4bcd57efd46eac38

Fix link in changelog Looks like this just got out of date at some point.

view details

David Hewitt

commit sha f36fb4a08bddb3508eca8b1fd78e2621797325ce

Merge pull request #1192 from PyO3/davidhewitt-patch-5 Fix link in changelog

view details

Syrus Akbary

commit sha e0775c363b11e1fd0ef18f4eb969a78225fe169c

Update Wasmer Python extension link

view details

Alex Gaynor

commit sha 5fe1a44277023e9fdb89b7438828a74605bc95bd

fixed markdown syntax

view details

David Hewitt

commit sha 309ab16b207bcfebc35dab63a7b6941bf0a96f68

Merge pull request #1194 from syrusakbary/patch-1 Update Wasmer Python extension link

view details

Yuji Kanagawa

commit sha c1b3e06a987ab808d7aaac71e0432f75c9193bd4

Merge pull request #1196 from alex/patch-1 fixed markdown syntax

view details

David Hewitt

commit sha 2213ab37b0eb407eac7f9afcf2335ab58b60e371

Fix doc redirect on release

view details

David Hewitt

commit sha 88358dee08e9390df7a98fa7ad21b57ea0a227d0

Merge pull request #1197 from davidhewitt/update-doc-redirect Fix doc redirect on release

view details

David Hewitt

commit sha ba360bc3cf57043e358fad296522055d4eba1385

Fix doc update on release Sorry for the noise, there were some errors in #1197 which github did not show until after I merged 😞

view details

David Hewitt

commit sha 037ec83d6e36df26ccc09dc77c052c5c02672505

Merge pull request #1198 from PyO3/davidhewitt-patch-5 Fix doc update on release

view details

David Hewitt

commit sha c05815520cc58db2a3fb2f79b3379ac043676e11

Release 0.12.1

view details

push time in 11 days

push eventPyO3/pyo3

David Hewitt

commit sha ba360bc3cf57043e358fad296522055d4eba1385

Fix doc update on release Sorry for the noise, there were some errors in #1197 which github did not show until after I merged 😞

view details

David Hewitt

commit sha 037ec83d6e36df26ccc09dc77c052c5c02672505

Merge pull request #1198 from PyO3/davidhewitt-patch-5 Fix doc update on release

view details

push time in 11 days

PR merged PyO3/pyo3

Fix doc update on release

Sorry for the noise, there were some errors in #1197 which github did not show until after I merged 😞

+2 -1

0 comment

1 changed file

davidhewitt

pr closed time in 11 days

PR opened PyO3/pyo3

Fix doc update on release

Sorry for the noise, there were some errors in #1197 which github did not show until after I merged 😞

+2 -1

0 comment

1 changed file

pr created time in 11 days

create barnchPyO3/pyo3

branch : davidhewitt-patch-5

created branch time in 11 days

push eventPyO3/pyo3

David Hewitt

commit sha 2213ab37b0eb407eac7f9afcf2335ab58b60e371

Fix doc redirect on release

view details

David Hewitt

commit sha 88358dee08e9390df7a98fa7ad21b57ea0a227d0

Merge pull request #1197 from davidhewitt/update-doc-redirect Fix doc redirect on release

view details

push time in 11 days

PR merged PyO3/pyo3

Fix doc redirect on release

Looks like the move from travis to actions for the guide accidentally broke the ability for https://pyo3.rs to automatically redirect to the latest version. (It's still going to 0.11.1.)

I believe this job should fix it; I'll merge and use it when releasing 0.12.1 shortly.

+21 -0

0 comment

1 changed file

davidhewitt

pr closed time in 11 days

issue closedPyO3/pyo3

Debug and Display for PyObject

With PyToken Diplay and Debug were implemented as follows. Those impls should be made available through some other kind of wrapper, e.g. like the .display() method on Path.

impl ::std::fmt::Debug for #cls {
    fn fmt(&self, f : &mut ::std::fmt::Formatter) -> Result<(), ::std::fmt::Error> {
        use ::pyo3::ObjectProtocol;
        let s = self.repr().map_err(|_| ::std::fmt::Error)?;
        f.write_str(&s.to_string_lossy())
    }
}
impl ::std::fmt::Display for #cls {
    fn fmt(&self, f: &mut ::std::fmt::Formatter) -> Result<(), ::std::fmt::Error> {
        use ::pyo3::ObjectProtocol;
        let s = self.str().map_err(|_| ::std::fmt::Error)?;
        f.write_str(&s.to_string_lossy())
    }
}

closed time in 11 days

konstin

issue commentPyO3/pyo3

Debug and Display for PyObject

Having thought about this, I concluded the correct solution is just to use as_ref(py) to get a PyAny, which implements both Display and Debug.

e.g.

let obj: PyObject = 1.into_py(py);
println!("obj is: {}", obj.as_ref(py));

Adding any other API would achieve exactly the same effect, so would be redudant.

konstin

comment created time in 11 days

pull request commentPyO3/pyo3

Release 0.12.1

As #1185 has been closed with conclusion that no fix needed, I'm going to proceed to release in a moment...

davidhewitt

comment created time in 11 days

PR opened PyO3/pyo3

Fix doc redirect on release

Looks like the move from travis to actions for the guide accidentally broke the ability for https://pyo3.rs to automatically redirect to the latest version. (It's still going to 0.11.1.)

I believe this job should fix it; I'll merge and use it when releasing 0.12.1 shortly.

+21 -0

0 comment

1 changed file

pr created time in 11 days

create barnchdavidhewitt/pyo3

branch : update-doc-redirect

created branch time in 11 days

issue commentPyO3/pyo3

Expose PyCapsule API

Yep exactly. Numpy uses it to share pointers to api functions; we can stash whatever we want in capsules 😄

davidhewitt

comment created time in 11 days

issue commentPyO3/pyo3

Specifying the minimum supported python version

Is it possible to use metadata from the package itself in pyo3's build.rs? Even if it is I'm not enthusiastic about doing that. OTOH Maturin could definitely check the cargo metadata, and setuptools-rust the pyproject.toml.

I wonder if we can add macros like rustversion ?

konstin

comment created time in 11 days

Pull request review commentPyO3/pyo3

Add documentation for raw_pycfuntion

 fn module_with_fn(py: Python, m: &PyModule) -> PyResult<()> {  # fn main() {} ```++## Accessing the FFI functions++In order to make Rust functions callable from Python, PyO3 generates a +`extern "C" Fn(slf: *mut PyObject, args: *mut PyObject, kwargs: *mut PyObject) -> *mut Pyobject`+function and embeds the call to the Rust function inside this FFI-wrapper function. This+wrapper handles extraction of the regular arguments and the keyword arguments from the input+`PyObjects`. Since this function is not user-defined but required to build a `PyCFunction`, PyO3+offers the `raw_pycfunction!()` macro to get the identifier of this generated wrapper.++E.g.:++```rust+use pyo3::prelude::*;+use pyo3::types::PyCFunction;+use pyo3::raw_pycfunction;++#[pyfunction]+fn some_fun() -> PyResult<()> {+    Ok(())+}++#[pymodule]+fn module(_py: Python, module: &PyModule) -> PyResult<()> {+    let ffi_wrapper_fun = raw_pycfunction!(some_fun);+    let docs = "Some documentation string with null-termination\0";+    let py_cfunction =+        PyCFunction::new_with_keywords(ffi_wrapper_fun, "function_name", docs, module.into())?;+    module.add_function(py_cfunction)+}++# fn main() {}+```

I think @kngwyu is correct; this document is great to go as a docstring on raw_pycfunction or maybe even `PyCFunction::new_with_keywords.

And then in the paragraph above can just have a link e.g. `(See the docs for raw_pycfunction).

I can't decide whether it's better for raw_pycfunction or PyCFunction::new_with_keywords though - happy for you to decide!

sebpuetz

comment created time in 11 days

PullRequestReviewEvent

Pull request review commentPyO3/pyo3

Add documentation for raw_pycfuntion

 fn module_with_fn(py: Python, m: &PyModule) -> PyResult<()> {  # fn main() {} ```++## Accessing the FFI functions++In order to make Rust functions callable from Python, PyO3 generates a +`extern "C" Fn(slf: *mut PyObject, args: *mut PyObject, kwargs: *mut PyObject) -> *mut Pyobject`+function and embeds the call to the Rust function inside this FFI-wrapper function. This+wrapper handles extraction of the regular arguments and the keyword arguments from the input+`PyObjects`. Since this function is not user-defined but required to build a `PyCFunction`, PyO3+offers the `raw_pycfunction!()` macro to get the identifier of this generated wrapper.++E.g.:++```rust+use pyo3::prelude::*;+use pyo3::types::PyCFunction;+use pyo3::raw_pycfunction;++#[pyfunction]+fn some_fun() -> PyResult<()> {+    Ok(())+}++#[pymodule]+fn module(_py: Python, module: &PyModule) -> PyResult<()> {+    let ffi_wrapper_fun = raw_pycfunction!(some_fun);+    let docs = "Some documentation string with null-termination\0";+    let py_cfunction =+        PyCFunction::new_with_keywords(ffi_wrapper_fun, "function_name", docs, module.into())?;+    module.add_function(py_cfunction)+}++# fn main() {}+```++The `wrap_pyfunction` macro can be used to directly get a `PyCFunction` given a+`#[pyfunction]` and a `PyModule`: `wrap_pyfunction!(rust_fun, module)`. In the single-argument+variant, the macro only takes the identifier of the Rust function and returns a function that+can be called with either `Python` or `PyModule` and returns a `PyCFunction`.

I think this paragraph may go into more detail than needed. (I'd rather not talk about the single-argument variant of wrap_pyfunction any more so that the ecosystem naturally migrates to the two-argument form.)

sebpuetz

comment created time in 11 days

PullRequestReviewEvent

issue commentPyO3/pyo3

Not raising a TypeError when it should after reversing the logical operator.

👍 thanks for investigating this even if it turned out we're already correct. Easiest bugfix ever! 😄

mvaled

comment created time in 11 days

push eventPyO3/pyo3

Syrus Akbary

commit sha e0775c363b11e1fd0ef18f4eb969a78225fe169c

Update Wasmer Python extension link

view details

David Hewitt

commit sha 309ab16b207bcfebc35dab63a7b6941bf0a96f68

Merge pull request #1194 from syrusakbary/patch-1 Update Wasmer Python extension link

view details

push time in 11 days

PR merged PyO3/pyo3

Update Wasmer Python extension link

We renamed the repo from python-ext-wasm to wasmer-python :)

+1 -1

1 comment

1 changed file

syrusakbary

pr closed time in 11 days

pull request commentPyO3/pyo3

Update Wasmer Python extension link

Thanks!

syrusakbary

comment created time in 11 days

PullRequestReviewEvent

issue openedPyO3/pyo3

Expose PyCapsule API

The capsule API (https://docs.python.org/3.8/c-api/capsule.html) can be useful for safely storing Rust data in a way that's not usable by Python without leaking it. This is possible because the capsule creation takes a destructor function.

Today it came up on Gitter that for rust-numpy it may be useful to do zero-copy transfer of arrays from Rust to Python, by stashing the backing storage (e.g. vec) in a capsule which is set as the base object to the numpy array.

created time in 12 days

delete branch PyO3/pyo3

delete branch : davidhewitt-patch-5

delete time in 12 days

push eventPyO3/pyo3

David Hewitt

commit sha 07f9ae2498fdd1906f676e3e4bcd57efd46eac38

Fix link in changelog Looks like this just got out of date at some point.

view details

David Hewitt

commit sha f36fb4a08bddb3508eca8b1fd78e2621797325ce

Merge pull request #1192 from PyO3/davidhewitt-patch-5 Fix link in changelog

view details

push time in 12 days

PR merged PyO3/pyo3

Fix link in changelog

Looks like this just got out of date at some point.

+1 -1

0 comment

1 changed file

davidhewitt

pr closed time in 12 days

PR opened PyO3/pyo3

Fix link in changelog

Looks like this just got out of date at some point.

+1 -1

0 comment

1 changed file

pr created time in 12 days

create barnchPyO3/pyo3

branch : davidhewitt-patch-5

created branch time in 12 days

PR opened PyO3/pyo3

Release 0.12.1

There's been a couple of bugfixes to 0.12 which I think warrant a patch release before we start merging any new / breaking changes on the way to 0.13.

I'd like to publish this tomorrow evening (16th Sep). We can always make further patch releases if necessary (hopefully not).

I think it would be nice if a bugfix for #1185 was also included in this release. @kngwyu, I'm not sure if you're already working on one, I'll have a go at writing a fix tomorrow evening if I don't hear a reason not to.

+14 -15

0 comment

6 changed files

pr created time in 12 days

create barnchPyO3/pyo3

branch : release-0.12.1

created branch time in 12 days

delete branch PyO3/pyo3

delete branch : release-0.12

delete time in 12 days

issue commentoconnor663/blake3-py

fix CI for 32-bit Windows

This was unfortunately a regression for 0.12; see https://github.com/PyO3/pyo3/pull/1179

A fix is merged and is incoming for 0.12.1 which I hope to find time to start publishing later today or tomorrow.

Sorry for the inconvenience.

oconnor663

comment created time in 12 days

issue commentPyO3/pyo3

Safely passing a mutable reference to Python?

👍 I've been busy the past few days but lurking on this conversation; I was going to say that pointers are probably better than transmuting lifetimes. I'm keen to take a read of your most recent solution when I have a chance. Thanks for looking into this!

raphlinus

comment created time in 13 days

push eventPyO3/pyo3

Matthew Treinish

commit sha a0960f891801c0534856cb90fa90451828579470

Fix compilation on platforms that don't use i8 for c_char (#1182) * 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

view details

push time in 13 days

PR merged PyO3/pyo3

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

+3 -1

4 comments

2 changed files

mtreinish

pr closed time in 13 days

issue closedPyO3/pyo3

0.12.0 non-x86 compile failure

🐛 Bug Reports

When reporting a bug, please provide the following information. If this is not a bug report you can just discard this template.

🌍 Environment

  • Your operating system and version: Linux (ubuntu 18.04 on ppc64le, s390x, and aarch64
  • Your python version: 3.7
  • How did you install python (e.g. apt or pyenv)? Did you use a virtualenv?:
  • Your Rust version (rustc --version):
  • Your PyO3 version: 0.12.0
  • Have you tried using latest PyO3 master (replace version = "0.x.y" with git = "https://github.com/PyO3/pyo3")?: no

💥 Reproducing

Building the pyo3 0.12.0 crate on non-x86 linux seems to fail because of a typing issue for a raw pointer. I started hitting this in CI for my downstream project when trying to upgrade to 0.12.0 here:

https://travis-ci.com/github/Qiskit/retworkx/jobs/384362604#L448 https://travis-ci.com/github/Qiskit/retworkx/jobs/384362605#L453 https://travis-ci.com/github/Qiskit/retworkx/jobs/384362606#L455

It looks like this was changed in https://github.com/PyO3/pyo3/commit/b9e95dc7c92b09d07e3a1f4a54e65d6753eda548#diff-8a0564885baee0a1d53807fd6ef013e5R448 the underlying issue is that a c_char can either be an i8 or u8 https://doc.rust-lang.org/std/os/raw/type.c_char.html and it looks like there is a mismatch on non-x86 systems.

Maybe we should just cast the input there as a c_char instead of i8?

(the error for when the travis log expires is below)

Running `rustc --crate-name pyo3 --edition=2018 /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -Cembed-bitcode=no --cfg 'feature="ctor"' --cfg 'feature="default"' --cfg 'feature="extension-module"' --cfg 'feature="indoc"' --cfg 'feature="inventory"' --cfg 'feature="macros"' --cfg 'feature="paste"' --cfg 'feature="pyo3cls"' --cfg 'feature="unindent"' -C metadata=cf6285843d911853 -C extra-filename=-cf6285843d911853 --out-dir /tmp/pip-req-build-xiu1t4n9/target/release/deps -L dependency=/tmp/pip-req-build-xiu1t4n9/target/release/deps --extern ctor=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libctor-d476a6cabbb1d5d0.so --extern indoc=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libindoc-53e0ec533919e29f.rmeta --extern inventory=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libinventory-68485ad54a661ce6.rmeta --extern libc=/tmp/pip-req-build-xiu1t4n9/target/release/deps/liblibc-76db962b748c2a37.rmeta --extern parking_lot=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libparking_lot-ae5080acef9548d0.rmeta --extern paste=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libpaste-be221bde5cca2a82.rmeta --extern pyo3cls=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libpyo3cls-5dbf26b63a171d5e.so --extern unindent=/tmp/pip-req-build-xiu1t4n9/target/release/deps/libunindent-fa42d75d448dc224.rmeta --cap-lints allow --cfg Py_3_5 --cfg Py_3_6 --cfg Py_3_7 --cfg Py_3 --cfg 'py_sys_config="WITH_THREAD"'`

  error[E0308]: mismatched types

     --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/pyo3-0.12.0/src/exceptions.rs:448:17

      |

  448 |                 input.as_ptr() as *const i8,

      |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`

      |

      = note: expected raw pointer `*const u8`

                 found raw pointer `*const i8`

  

  error: aborting due to previous error

  

  For more information about this error, try `rustc --explain E0308`.

  error: could not compile `pyo3`.

closed time in 13 days

mtreinish

pull request commentPyO3/pyo3

Fix compilation on platforms that don't use i8 for c_char

Many thanks!

mtreinish

comment created time in 13 days

pull request commentPyO3/pyo3

Fix compilation on platforms that don't use i8 for c_char

If you have a moment, could you please add a changelog entry? Else I'll merge this sometime tomorrow and write a changelog entry at the same time.

mtreinish

comment created time in 14 days

pull request commentPyO3/setuptools-rust

Use Github Actions instead of Travis

CI passed 🎉 . So this is blocked until PyO3 0.12.1 releases.

davidhewitt

comment created time in 14 days

pull request commentPyO3/setuptools-rust

Use Github Actions instead of Travis

I think I missed one of the toml files, so have pointed that one also at master and re-pushed.

davidhewitt

comment created time in 14 days

pull request commentPyO3/pyo3

Fix compilation on platforms that don't use i8 for c_char

👍 thanks very much for debugging this, sorry for the bug I introduced!

mtreinish

comment created time in 14 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha c4a1244b5affbbb51371937587c94f3d8afbe8d1

Use pyo3 master

view details

push time in 14 days

pull request commentPyO3/setuptools-rust

Use Github Actions instead of Travis

As https://github.com/PyO3/pyo3/pull/1179 is now merged, I'm testing this PR against the pyo3 master. Hopefully green!

davidhewitt

comment created time in 15 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha 01128ce217af5b4a504756048a22d90695e42802

Use pyo3 master

view details

push time in 15 days

pull request commentPyO3/setuptools-rust

Use Github Actions instead of Travis

Agreed; it's pretty late here so I'm going to finish this tomorrow. Ideally in the morning but could be later in the day...

davidhewitt

comment created time in 15 days

pull request commentPyO3/pyo3

Add documentation for raw_pycfuntion

(Just a note to say thanks very much for writing these docs; I've been very busy lately, hoping to find time to read through these and review hopefully Monday.)

sebpuetz

comment created time in 15 days

push eventPyO3/pyo3

David Hewitt

commit sha 5ad89de17002515ff413e7e26cad16083f5dcfaf

Fix date in changelog

view details

David Hewitt

commit sha 00a87008dcc885bf79a921c6e826386a2dfce020

Merge pull request #1178 from davidhewitt/fix-changelog-date Fix date in changelog

view details

push time in 15 days

PR merged PyO3/pyo3

Fix date in changelog

With thanks to @sebpuetz for noticing this! 🤦

+3 -2

0 comment

1 changed file

davidhewitt

pr closed time in 15 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha 070006139269988ec136eb240e7422a042108162

Use Github Actions instead of Travis

view details

push time in 15 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha c4df7c0fabe569202ca13760455945c327b2b0a2

Use Github Actions instead of Travis

view details

push time in 15 days

push eventdavidhewitt/setuptools-rust

David Hewitt

commit sha 2704a9a263764db263235cfed99e538328a6c796

Release 0.11.1

view details

David Hewitt

commit sha fbf8aa567988d997c90f5d982d5f5e9c3a66e9f9

Fix support for namespace packages

view details

David Hewitt

commit sha de4489d390c707f3f5150ec1a1bec2efffa2255a

Merge pull request #79 from davidhewitt/namespace-packages Fix support for namespace packages

view details

David Hewitt

commit sha fa2ee8e9d8ccda09d00f3de72e2858de8ad8d06a

Release 0.11.2

view details

Alex Gaynor

commit sha 967a9fb012d38da6a766ccf2df51f086f27754ec

Fix building for musl libc

view details

David Hewitt

commit sha d931ccd219fced93703066d2da5def924224757d

Merge pull request #80 from alex/musl-build Fix building for musl libc (alpine linux)

view details

David Hewitt

commit sha 16a111d33682a429ef4fc0d468d225ee53807fa5

Release 0.11.3

view details

David Hewitt

commit sha ed902ab6681b168c55fcb8967648f63e51b4565c

Use Github Actions instead of Travis

view details

push time in 15 days

pull request commentPyO3/pyo3

Don't consider it cross-compilation when building for 32-bit Windows on 64-bit windows

Thanks, nice catch. I thought our CI would catch this when I commented it seemed a possible breakage in #1095, but at the time CI suggested it was ok (and I was suprised but let it slide). Can you add a CHANGELOG entry please? (fixed section)

I will rebase the setuptools-rust github actions CI PR I had, which I guess will find the same issue.

Might give this a couple days once merged before releasing just so that 0.12.1 can include fixes for any other painful oversights!

alex

comment created time in 15 days

PR opened PyO3/pyo3

Fix date in changelog

With thanks to @sebpuetz for noticing this! 🤦

+3 -2

0 comment

1 changed file

pr created time in 15 days

create barnchdavidhewitt/pyo3

branch : fix-changelog-date

created branch time in 15 days

push eventPyO3/pyo3

David Hewitt

commit sha 32be8d9a3c463fbc3689b57680d73953355b36e0

Release 0.12

view details

David Hewitt

commit sha b7f45c4fbfbf9b5ddc381c4c4a487b01847a6840

Merge pull request #1173 from PyO3/release-0.12 Release 0.12

view details

push time in 15 days

PR merged PyO3/pyo3

Release 0.12

Closes #1104

This is a PR drafting the release of pyo3 0.12! 🎉

I've bumped the version numbers and edited the contents of the changelog to be as consistent and simple as I could make it.

I propose the following release text (links don't work yet as they point to the 0.12 guide). Please post any suggested changes.

If I don't hear reasons otherwise, I plan to put this release live on Saturday evening. (12th September)


This release has seen a few careful revisions to the PyO3 API with the goal of making it easier to learn and use. The PyErr type has been reworked to implement std::error::Error. The FromPy trait is removed. The PyObject struct is now just a simple type alias to Py<PyAny>.

Also added is a new #[derive(FromPyObject)] macro, which enables a convenient way to accept arguments of the Python "type" Union. (See the guide entry on this new feature.)

There have been many other improvements and bugfixes too numerous to go into detail here. For the full list, see the CHANGELOG.


Many thanks to you all who have helped design and implement this release!

+53 -53

1 comment

6 changed files

davidhewitt

pr closed time in 15 days

issue closedPyO3/pyo3

0.12 Release

While the original issues I marked out for the 0.12 milestone are still not yet completed, I think that master already contains a lot of changes compared to 0.11.1.

So I'm tempted to suggest we push most of the outstanding issues from the 0.12 milestone into the 0.13 milestone (unless there is sudden movement on any of them) and start heading towards releasing 0.12. I think it doesn't really matter if the rest of the proposals don't land until 0.13.

This is what I still think should probably happen before an 0.12 release (as well as anything else people contribute):

  • [x] Write migration guide entry related to the exception changes I landed in #1024 .
  • [x] Ideally I'd still like the three tickets related to PyErr to be completed (#592, #682, #1034), given that #1024 laid the groundwork for this to be possible.
  • [x] It would be nice to finish off the doc ticket #376
  • [x] @kngwyu finishing a fix for #844
  • [ ] #[pyenum] #1045
  • [x] #[derive(FromPyObject)] #1065

Any thoughts?

closed time in 15 days

davidhewitt

Pull request review commentPyO3/pyo3

Release 0.12

 PyO3 versions, please see the [migration guide](https://pyo3.rs/master/migration The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). -## [Unreleased]+## [0.12.0] - 2020-10-12

Oh haha oops, I just released! I'll merge this now and then fix on master :)

davidhewitt

comment created time in 15 days

PullRequestReviewEvent

created tagPyO3/pyo3

tagv0.12.0

Rust bindings for the Python interpreter

created time in 15 days

release PyO3/pyo3

v0.12.0

released time in 15 days

more