Skip to content

Consider removing the blanket FromPyObject for T: PyClass + Clone ? #5419

@davidhewitt

Description

@davidhewitt

I wonder, should we remove the FromPyObject implementation for T: PyClass + Clone while we're making all the changes in 0.27? (Orginally introduced in #730)

I feel like there are several drawbacks to having that implementation:

  • it makes the error messages for .extract() always error that X: PyClass is not satisfied due to the blanket (maybe we can fix this with a better diagnostic::on_unimplemented for FromPyObject)
  • it makes it easy for users to accidentally clone their data when receiving it as an argument from Python
  • it makes it impossible to add users' own FromPyObject implementation for #[pyclass] types which implement Clone, due to the blanket. (Unable to implement FromPyObject for #[pyclass] with Clone #4337)

While we're breaking FromPyObject, should we consider removing this implementation?

I can also see an argument for keeping the blanket and instead just documenting it better to mitigate the downsides, to some users it may be convenient and it would be more breakage to remove it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions