I'd prefer a lifetime to be attached to the type, to avoid use after free. Is there any reason there can't be one?

Alternatively, my vision for single-indirection borrowed pyobject was a that PyObjectRef implements Deref<Target=PyObject>, so that instead of PyObjectPtr it'd be &PyObject and the with_ptr would just be implicit from Deref coercion

@coolreader18 Thanks! lifetime is really helpful advice. I didn't understand the &PyObject idea that much. If PyObjectRef deref to &PyObject<Erased>, how do we get PyObjectRef back again?

Just PyObjectRef::from_raw. Like to_owned for it could look like let m = ManuallyDrop::new(PyObjectRef::from_raw(self as *const _ as *const PyObjectRaw)); m.clone(). Should I make a branch of what I was thinking?

@coolreader18 yes, that sounds great

@youknowone see borrowed-pyobj

@coolreader18 looks good

mm, it has problem

@coolreader18 could you help it please?

@youknowone ok! I think the main issue was the downcast_ref(&&self) -> &PyRef<T> casting, or at the very least switching to &Py<T> fixed whatever was causing the segfault. I think it'd be best to merge asap, since merge conflicts are probably likely with this kind of mass edit.

Could we remember to document these central types? The PR includes two additional public facing types that will inevitably confuse folks trying to contribute/understand to the/the codebase.

incref is not a rust concept. So removed it and replaced it with to_owned. The name Py is too much generic. Any suggestion? It must be used only as reference.

Renamed a few types not to expose PyObj and Py. Not sure about the name PyObjectView but at least it could be renamed easier than Py.

@DimitrisJim I agree they must be documented better.

Yea, I'm planning on making some follow-up PRs