Dealing with integer status codes is un-pythonic

[asokoloski]

I'd like to change the api model schema a bit in order to allow generation of bindings that take the integer status code (0=success, otherwise failure) returned by a method and raise a python exception instead.

Something like one of these:

<return type="status_code" />
<return type="integer" is_status="1" />
<return type="integer" kind="status">

or

<method ... returns_status = "1">...</method>

At the risk of inviting bikeshedding, any reason to prefer one over the others? If not I'll probably go with the second one.

[asokoloski]

Actually, I think the first option, , is a bit cleaner and doesn't require as many changes as I predicted.

[hintjens]

When defining types, always try to avoid splitting the semantics. Integer/status suggests there are other kinds of integer, or other kinds of status. Be explicit. "Status" is kind of overloaded.

Note the integer return value is not true/false (otherwise we'd use boolean), it's -1 = failure, 0 or greater is success. So what you're really trying to express is "-1 means exception".

How about ''?

On Thu, Feb 4, 2016 at 6:25 PM, Aaron Sokoloski [email protected] wrote:

Actually, I think the first option, , is a bit cleaner and doesn't require as many changes as I predicted.

— Reply to this email directly or view it on GitHub https://github.com/zeromq/zproject/issues/530#issuecomment-179956305.

[asokoloski]

Hmm, to me doesn't really give any indication that a negative return value is expected in certain situations, or that it means that the method failed.

I agree that "status" is an overloaded term. How about something like this?

<return type = "integer" error_value = "-1" />

I think that clearly encodes "-1 means exception" as you described. Or in the case where any negative value means error:

<return type = "integer" error_value = "negative" />

I don't quite like how negative is an adjective, while error_value implies a single value, though. Maybe something like "on_error" instead of "error_value"?

This is flexible enough to encode error values for other return types (returning NULL for a pointer?), although I think it would make sense to explicitly limit it to integer return types for now.

Thoughts?

[hintjens]

Let's use 'status' as the simplest plausible solution.

On Thu, Feb 4, 2016 at 7:53 PM, Aaron Sokoloski [email protected] wrote:

Hmm, to me doesn't really give any indication that a negative return value is expected in certain situations, or that it means that the method failed.

I agree that "status" is an overloaded term. How about something like this?

I think that clearly encodes "-1 means exception" as you described. Or in the case where any negative value means error:

I don't quite like how negative is an adjective, while error_value implies a single value, though. Maybe something like "on_error" instead of "error_value"?

This is flexible enough to encode error values for other return types (returning NULL for a pointer?), although I think it would make sense to explicitly limit it to integer return types for now.

Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/zeromq/zproject/issues/530#issuecomment-179999216.

[asokoloski]

Ok, sounds good. Thanks.

[twhittock]

It's worth noting that there's no implication that generated bindings would or should be idiomatic. The python bindings explicitly state they are not intended to be that.

The zproject API structure isn't particularly high-level - little information is available about ranges or semantics, nor does it have high level container types, etc. IMO, the binding generators are there to take the repetitive grunt work out of a 'translation layer' which can then be easily wrapped with something a human can regard as idiomatic in the target language.

As for status codes, there is little benefit in finding some piece of code has raised MyProjectException(-15) if there is no information about what -15 could mean - a status code on its own is of little use, especially to someone divorced from the actual project by a language barrier. I would personally prefer going down some sort of enum-style route, such that the enum has a name which identifies the error, and could even be marked as an error type if automatic exception raising is needed. In this way, semantic information is added to the system and we step towards something which could theoretically generate idiomatic bindings.