-
Notifications
You must be signed in to change notification settings - Fork 760
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile with stable rust #5
Comments
Doesn't proc macro work on stable rust? (or just partially) And there is proc-macro2 |
I think currently only proc macro for custom derive works on stable Rust, |
|
Can this trick be used instead of |
no, it is not. pyo3 strictly requires |
I think this is exactly what it does, i.e. given the example:
The And all this works by wrapping a body of the macro into a type definition to leverage macros 1.1, to get a token stream. The only difference is that:
Would be written as:
|
I see. But that would be quite large task, I don’t think I can spend any time on it. Also there is specialization, I am not sure if it possible to avoid it If you want to work on this task I can give you permission to repo |
this features are stable now, const_unsafe_cell_new, const_size_of, const_ptr_null, const_ptr_null_mut |
Stabilization of TryFrom has been reverted rust-lang/rust#50121 |
pyo3 does not use TryFrom |
Line 183 in 9dc7661
The macro pyobject_extract! uses TryFrom . To use PyO3 in stable rust, this library itself must be compiled with stable rustc.IMHO, there is no merit to use this unstable feature, and should be dropped. |
This was discovered PyO3#5 (comment)
@termoshtt Good catch! pyo3 implements TryFrom, even though it currently uses PyTryFrom instead. I put a feature gate onto the implementation of TryFrom and removed the try_from feature. Once TryFrom becomes stable, we can than replace PyTryFrom. |
Drop of
|
Unfortunately not, specialization is still not stable |
I'm trying to compile a Python Any insights?
|
Nope. Nightly builds have additional feature flags turned on, most of which won't make it to the next stable release, so 1.34.0-nightly has a lot more features than 1.35.0 (including specialization). |
I find the message confusing due to the second line:
I wanted to create an issue about this, but luckily found this. Also, how about telling Python users who are newbies to rust how to get the nightly version right in the error message? I did it using |
@konstin any thoughts on whether dtolnay's trick https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md linked to by @io12 above would be a feasible/pragmatic way to for this library to compile on stable? |
Having to use not only a new programming language, but the unstable version of that language, is not something I feel comfortable pitching to my coworkers (no matter how stable nightly actually may be). Because easy python interoperability is a necessity for any new language that my work would use, and because it seems like there aren't other options with the same level of python interoperability with Rust that Py03 provides, I cannot in good faith pitch using rust at work until this is using the stable version of rust 😢 |
@TheButlah: You can create libraries to interoperate with python without using PyO3. Don't confuse the library with the language. You can currently either create native library bindings for your rust code, and interface with them using cffi, or use https://github.com/dgrunwald/rust-cpython. PyO3 provides a nicer interface, it's true, but if your requirement is stable rust, that interface isn't available to you. |
Bump: Is there any ETA / update on stable rust toolchain? |
Progress slowly continues; we want to get there but need more volunteer time to get this over the finish line yet. (pyo3 maintainer time in the last few months has been spent mostly on soundness problems as well as bugfixes, which are also very important.) Last items to resolve are in #697. I can offer mentoring advice to anyone interested in helping out with pieces of the solution in there. |
@jcdyer The emphasis is on easy interoperability, not just any interoperability, which is the purpose of PyO3. That being said, I did pitch rust to my coworkers, and got enough leeway to experiment with it in a side project - because I realized that nightly wasn't as bad as it sounded. That being said, I work in a research lab not an enterprise company and our risk tolerance for these sorts of things is significantly higher, so continuing to focus on using stable would be a big selling point for the language overall. Glad to see how active this community is - it says a lot about the language and ecosystem :) |
Yeah, I also think it's a matter of time. |
Hello. It appears to me, from reading #210, that specialisisation is mostly used to implement class declaration. So how hard would it be to introducing a feature Once specialisation is stable or pyo3 managed to get rid of it, class declaration would be allowed in An alternative would be the other way around: Make |
if we're going to use a cargo feature, we should use the enable unstable code feature rather than the disable version, since cargo features should be additive since that's how cargo's designed. as an example, if one crate uses the unstable code and another one doesn't, then using the enable version of the feature would correctly deduce that unstable code should be enabled for the crate that requires it. if it was the disable version then cargo would incorrectly disable the unstable code even though a crate requires it, leading to compile failure. If anything requires unstable code, then you need to use the unstable compiler on all the crates anyway in order to have the compiler versions match, so that's not a limitation. |
Make sense. The reason I thought it up the other way round is, that it might make things appear from the documentation, but one should be able to work around this. |
Hi. I don't know a lot about Rust, but trying to run an application I use often that recently introduced bits of rust. |
Read comments above, work is ongoing to fix this but it takes time... |
@sinetek The answer to the question you asked is in the thread above. If you would like to get it working, the recommended way to work with rust as a developer is to use rustup to manage your rust toolchains, so you can have nightly and stable running side by side. You can get rustup from https://rustup.rs. Then run the following:
Then when you want do run on stable, you can switch back with You can find more detail here: https://github.com/rust-lang/rustup#working-with-nightly-rust |
For all those following this thread... the current PyO3 master branch just had a PR merged which added support for stable Rust. Extra special thanks to @kngwyu and @konstin who have been working to remove specialization from PyO3 for a long time - and as of this morning, we finally got there! 🎉 🚀 🐍 🦀 |
Cheers!
…On Sun, Jun 21, 2020, 10:06 David Hewitt ***@***.***> wrote:
For all those following this thread... the current PyO3 master branch just
had a PR merged which added support for stable Rust.
Extra special thanks to @kngwyu <https://github.com/kngwyu> and @konstin
<https://github.com/konstin> who have been working to remove
specialization from PyO3 for a long time - and as of this morning, we
finally got there! 🎉 🚀 🐍 🦀
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFPQGZCMZPNWNYAXGESIS3DRXW5RBANCNFSM4DMCSS4Q>
.
|
That's awesome progress you've been making this past 6 months! Huge congratulations on all your efforts. |
excitement intensifies |
congrats! |
PyO3 requires following unstable
Optional, forSolved with mashupwrap_function!
: concat_idents (Tracking issue forconcat_idents
rust-lang/rust#29599)The text was updated successfully, but these errors were encountered: