On 26May2012 21:28, Antoine Pitrou <solip...@pitrou.net> wrote:
| Not only does the error string contain more valuable information (the
| mnemonics "SSL" and "CERTIFICATE_VERIFY_FAILED" indicate, respectively,
| in which subpart of OpenSSL and which precise error occurred), but they
| are also introspectable:
|
| >>> e = sys.last_value
| >>> e.library
| 'SSL'
| >>> e.reason
| 'CERTIFICATE_VERIFY_FAILED'
|
| (these mnemonics correspond to OpenSSL's own #define'd numeric codes. I
| find it more Pythonic to expose the mnemonics than the numbers, though.
| Of course, the numbers <-> mnemnonics mappings can be separately
| exposed)
Would you be inclined to exposed both? Eg add .ssl_errno (or whatever
short name is conventionally used in the SSL library itself, just as
"errno" matches the POSIX error code name).
| You'll note there is still a "Errno 5" in that error message; I don't
| really know what to do with it. Hard-wiring the errno attribute to
| something like None *might* break existing software, although that
| would be unlikely since the current errno value is quite meaningless
| and confusing (it has nothing to do with POSIX errnos).
It is EIO ("I/O error"), and not inappropriate for a communictions failure.
I don't think POSIX prohibits other library functions from setting errno,
either.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Principles have no real force except when one is well fed. - Mark Twain
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
