-
Notifications
You must be signed in to change notification settings - Fork 126
result*() shouldn't raise on a message with non-successful result #278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 2, 2019
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 2, 2019
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 2, 2019
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 2, 2019
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
Apr 30, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
Apr 30, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
Apr 30, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
Apr 30, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 7, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
mistotebe
added a commit
to mistotebe/python-ldap
that referenced
this issue
May 18, 2020
Would be nice if result4 returned the operation result as well (but for that we'd need to expose the result codes too, at the moment all of them are just exceptions that can't even be converted to ints).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description:
I'm writing an asyncio wrapper (https://gist.github.com/mistotebe/7bbc48ce20c8dc82f6885b370353be60) and got hit by the issues #177 and #208. And there is no way to avoid an exception to be raised (it is coming from the C code).
My proposal is to allow the actual message to be returned from
result*
methods and issue exceptions from the*_s
methods where appropriate.Steps to reproduce:
Have the server return an error result to a request, call client.result*() to read it.
Operating system:
Any. (Debian buster)
Python version:
Any. (3.7.3rc1)
python-ldap version:
Any? (3.1.0)
The text was updated successfully, but these errors were encountered: