Py::new might not need to return PyResult

[davidhewitt]

At the moment Py::new returns PyResult<Py<T>>, though in discussion in #1074 (comment) we came to concensus that it can probably just return Py<T>. The only error situation which can occur is out-of-memory. Most other pyo3 constructors where this is the only error situation just panic on OOM. (This is the same in the Rust stdlib.)

At the moment this fallibility comes down to PyClassAlloc::new returning nullptr on any error. And also PyClassAlloc::new can allocate a subtype, which could run arbitrary code through the subtype's tp_alloc.

If PyClassAlloc::new was split into e.g. ::new and ::new_subtype, where ::new always allocates Self, then we should be able to refactor code enough to change semantics of Py::new so that it panics on OOM.

pyo3/src/pycell.rs

Lines 374 to 377 in f2ba3e6

	let base = T::new(py, subtype);
	if base.is_null() {
	return Err(PyErr::fetch(py));
	}

[davidhewitt]

It was interesting to note for pyclasses that x.into_py(py) is infallible, whereas Py::new(py, x) is fallible - which adds weight to the argument that Py::new doesn't need to return result.

[birkenfeld]

Candidate for 0.12?

[davidhewitt]

Would be cool but I'm slightly concerned the limited API may affect the code paths here, so I think we should coordinate this with the abi3 work in 0.13.

[davidhewitt]

Further thinking on this subject is that perhaps Rust types which subclass Python types could be fallible to construct, so this issue probably shouldn't be implemented before #991.

[davidhewitt]

I think with #4041 we are now thinking that into-python conversions will likely be fallible in the future, and given the subclassing issue above I think the general conclusion is that this should stay fallible (as it currently is).