Possible ergonomics (or better documentation) opportunities for #[derive(FromPyObject)]

I was struggling a while to get something like this to work:

// Union-type for arguments to arithmetic operations.
#[derive(FromPyObject)]
pub enum IntOrElemArg<'a,T> {
  Obj(&'a T), // intended to be Self
  ZZ(&'a PyZZ), // another #[pyclass]
  Literal(RugInteger), // RugInteger implements FromPyObject
}

This naive approach failed for me. Maybe there is a way to get it to work, but I didn't find it. I finally figured out I need to change it to be:

#[derive(FromPyObject)]
pub enum IntOrElemArg<'a,T> {
  Obj(T),
  ZZ(PyRef<'a,PyZZ>),
  Literal(RugInteger),
}

impl<'a,T: PyClass> IntOrElemArg<'a,PyRef<'a,T>> { ... }

And can then only use it as IntOrElemArg<PyRef<Self>>. Putting PyRef<'a,T> into the enum directly there doesn't seem to be a way to indicate to the proc-macro that T: PyClass because the struct-constraint on PyRef infects upward?

No file or test is named in the issue. Start by reproducing the two #[derive(FromPyObject)] enum forms and reviewing the derive behavior for PyRef, PyClass, and generic bounds; done means either a workable ergonomic approach is identified or the limitation and workaround are documented.