Btw, I think we should avoid these, returning a tuple in a library is very tricky it's not really something people expect to retrieve.

If we keep it, it should be really well documented

(Note: I place the comment here, but this is valid elsewhere)

Yes, users won't expect this type of return value. Do you have some ideas about how shall we change it? I think it would be helpful if users can know why was the operation failed :)

Learned a lot from it, thank you very much!

I will merge this now and modify the return value of the POST methods, changing the return value from tuple to a dictionary, and modify the function description strings ;)

I will merge this now and modify the return value of the POST methods, changing the return value from tuple to a dictionary, and modify the function description strings ;)

I don't think this is the right approach, I can think of two ways:

1/ just return the message and let the user deal with it. After all most of the
time the consumer will just display the message and let the user (human) deal
with it.

2/ check the returned message and raise an exception when something went wrong.
The message of the exception could be the content of the returned message, thus
the description of the error.

I will merge this now and modify the return value of the POST methods, changing the return value from tuple to a dictionary, and modify the function description strings ;)

I don't think this is the right approach, I can think of two ways:
1/ just return the message and let the user deal with it. After all most of the
time the consumer will just display the message and let the user (human) deal
with it.
2/ check the returned message and raise an exception when something went wrong.
The message of the exception could be the content of the returned message, thus
the description of the error.

I think you are right. We should return straightforward results. I've implemented method 2, when there is no error, it returns "True" and otherwise raises an error containing the return message.

I will merge this now and modify the return value of the POST methods, changing the return value from tuple to a dictionary, and modify the function description strings ;)

I don't think this is the right approach, I can think of two ways:
1/ just return the message and let the user deal with it. After all most of the
time the consumer will just display the message and let the user (human) deal
with it.
2/ check the returned message and raise an exception when something went wrong.
The message of the exception could be the content of the returned message, thus
the description of the error.

I think you are right. We should return straightforward results. I've implemented method 2, when there is no error, it returns "True" and otherwise raises an error containing the return message.

The question becomes: is there an interest of the method to return something?

It could simply be, everything works and it's cool or we raise an exception.
Return True in this case doesn't bring any information over returning None (ie
not returning anything)

I will merge this now and modify the return value of the POST methods, changing the return value from tuple to a dictionary, and modify the function description strings ;)
I don't think this is the right approach, I can think of two ways:
1/ just return the message and let the user deal with it. After all most of the
time the consumer will just display the message and let the user (human) deal
with it.
2/ check the returned message and raise an exception when something went wrong.
The message of the exception could be the content of the returned message, thus
the description of the error.

I think you are right. We should return straightforward results. I've implemented method 2, when there is no error, it returns "True" and otherwise raises an error containing the return message.

The question becomes: is there an interest of the method to return something?
It could simply be, everything works and it's cool or we raise an exception.
Return True in this case doesn't bring any information over returning None (ie
not returning anything)

Yes, I agree with you :) There is no obvious need for an actual return value. I've updated it.