Better names for PyErr::ptype, PyErr::pvalue and PyErr::ptraceback

[davidhewitt]

I keep thinking I'd like to give nicer names for PyErr::ptype, PyErr::pvalue, and PyErr::ptraceback.

As far as I'm aware the "p" prefix is a hangover from C hungarian notation; it feels very out of place here as we're not even returning raw pointers from these methods.

I would love to have just .type, .value and .traceback but type is a reserved keyword.

Could potentially be .get_type, .value, and .traceback (inspired by PyAny::get_type which is presumably trying to solve the same problem). Or get_ prefix for all three, but that feels slightly more verbose than it needs to be.

Any ideas welcome.

[birkenfeld]

err.r#type() 😄

[davidhewitt]

I mean while technically possible, I don't think I want that 😅

[Eric-Arellano]

Maybe .err_type? I like .get_type() otherwise

[mejrs]

Some people resort to kind because of this.

[davidhewitt]

Yes, I used kind in a recent piece of pyo3-macros-backend code. However, I think that given Python calls this thing the "exception type", I'm unconvinced kind works here...

[birkenfeld]

kind is also quite unfamiliar to Python programmers. get_type() is clear and nicer than type_() which would be the other convention to avoid clashes.

[davidhewitt]

Yes I think I'm quite happy with get_type too. I just can't decide whether the other methods should be get_value/value and get_traceback/traceback.

Maybe get_value & get_traceback for consistency? get_ isn't that long a prefix and these methods aren't used that frequently...

[Eric-Arellano]

I personally like traceback(py) and value(py) more than using get_. I think having to pass Python as an arg already makes clear it's a getter and that it's more than just reading from a struct.

While the inconsistency is a little weird, I don't think it's the end of the world. And not every call site will use all 3 (I think pants only needed traceback)

[mejrs]

err.r#type() 😄

If we're going for familiarity to Python programmers, this is (I think) the only thing that emits a helpful compiler error when .type() is tried. So perhaps we should not be so quick to dismiss it.

[davidhewitt]

True, but we already have PyAny::get_type, which I'm not aware of having been confusing to any users.