You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the answers to #296 I gather that it's not currently possible to have Rust-implemented pyclasses be subclasses of regular Python classes. As far as I can tell, the docs don't mention this explicitly and the relevant section only talks about classes that are available as Rust types (like user-defined pyclasses and the ones that come with PyO3).
In my opinion, it wouldn't hurt to mention this explicitly in the docs, both in the text and in the reference table entry for extends. Someone else also requested this in #296 (comment).
I thought that maybe the reason it isn't mentioned is that this is a limitation of Python extension types in general rather than one of PyO3, but Python's docs on the issue say only that deriving extension types from built-in rather than custom Python types is the easiest option, not that it's the only one.
The text was updated successfully, but these errors were encountered:
Discussion of the intent to support this is in #991. It's mostly a question of balancing this against many other priorities for PyO3. I would be happy to have this supported.
From the answers to #296 I gather that it's not currently possible to have Rust-implemented pyclasses be subclasses of regular Python classes. As far as I can tell, the docs don't mention this explicitly and the relevant section only talks about classes that are available as Rust types (like user-defined pyclasses and the ones that come with PyO3).
In my opinion, it wouldn't hurt to mention this explicitly in the docs, both in the text and in the reference table entry for
extends
. Someone else also requested this in #296 (comment).I thought that maybe the reason it isn't mentioned is that this is a limitation of Python extension types in general rather than one of PyO3, but Python's docs on the issue say only that deriving extension types from built-in rather than custom Python types is the easiest option, not that it's the only one.
The text was updated successfully, but these errors were encountered: