Skip to content
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

Cannot use &PyClass as argument type in protocol methods #940

Closed
davidhewitt opened this issue May 19, 2020 · 2 comments
Closed

Cannot use &PyClass as argument type in protocol methods #940

davidhewitt opened this issue May 19, 2020 · 2 comments
Labels

Comments

@davidhewitt
Copy link
Member

🌍 Environment

  • Your PyO3 version: 0.10.1
  • Have you tried using latest PyO3 master (replace version = "0.x.y" with git = "https://github.com/PyO3/pyo3")?: Yes

💥 Reproducing

Create a custom object #[pyclass], let's call it MyClass.

Try to use &MyClass as a function argument in a #[pyproto] block:

use pyo3::prelude::*;
use pyo3::basic::{CompareOp, PyObjectProtocol};

#[pyclass]
pub struct MyClass {}

#[pyproto]
impl PyObjectProtocol for MyClass {
    fn __richcmp__(&self, other: &MyClass, op: CompareOp) -> PyResult<()> {
        unimplemented!()
    }
}

This will fail to compile:

error[E0277]: the trait bound `&MyClass: pyo3::pyclass::PyClass` is not satisfied
   --> src\lib.rs:7:1
    |
7   | #[pyproto]
    | ^^^^^^^^^^ the trait `pyo3::pyclass::PyClass` is not implemented for `&MyClass`
    |
   ::: C:\Users\david\dev\pyo3\src\class\basic.rs:140:17
    |
140 |     type Other: FromPyObject<'p>;
    |                 ---------------- required by this bound in `pyo3::class::basic::PyObjectRichcmpProtocol`
    |
    = help: the following implementations were found:
              <MyClass as pyo3::pyclass::PyClass>
    = note: required because of the requirements on the impl of `pyo3::conversion::FromPyObject<'p>` for `&MyClass`
    = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

I expect this broke on 0.9.0 when we changed so that &PyClass implements derive_utils::ExtractExt instead of FromPyObject.

cc @kngwyu - I guess that when you refactor protocol methods to remove specialization this problem might automatically be fixed at the same time. It could be interesting to add a test for it then.

@kngwyu
Copy link
Member

kngwyu commented Jun 21, 2020

I don't think it's possible. Users can use &PyRef instead.
To enable this, we need a more complex trait that can represent T: FromPyObject or U: FromPyObject, U: Deref<Target = T>.

I guess that when you refactor protocol methods to remove specialization this problem might automatically be fixed at the same time.

I don't think they're related.

@kngwyu kngwyu closed this as completed Jun 21, 2020
@davidhewitt
Copy link
Member Author

Ok cool, thanks for the feedback 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants