Re: [Python-Dev] cpython: #12586: add provisional email policy with new header parsing and folding.
Am 26.05.2012 00:44, schrieb r.david.murray: > http://hg.python.org/cpython/rev/0189b9d2d6bc > changeset: 77148:0189b9d2d6bc > user:R David Murray > date:Fri May 25 18:42:14 2012 -0400 > summary: > #12586: add provisional email policy with new header parsing and folding. > > When the new policies are used (and only when the new policies are explicitly > used) headers turn into objects that have attributes based on their parsed > values, and can be set using objects that encapsulate the values, as well as > set directly from unicode strings. The folding algorithm then takes care of > encoding unicode where needed, and folding according to the highest level > syntactic objects. > > With this patch only date and time headers are parsed as anything other than > unstructured, but that is all the helper methods in the existing API handle. > I do plan to add more parsers, and complete the set specified in the RFC > before the package becomes stable. > > files: > Doc/library/email.policy.rst | 323 + > Lib/email/_encoded_words.py | 211 + > Lib/email/_header_value_parser.py| 2145 > Lib/email/_headerregistry.py | 456 + > Lib/email/_policybase.py |12 +- > Lib/email/errors.py |43 +- > Lib/email/generator.py |11 +- > Lib/email/policy.py | 173 +- > Lib/email/utils.py | 7 + > Lib/test/test_email/__init__.py | 6 + > Lib/test/test_email/test__encoded_words.py | 187 + > Lib/test/test_email/test__header_value_parser.py | 2466 ++ > Lib/test/test_email/test__headerregistry.py | 717 ++ > Lib/test/test_email/test_generator.py| 170 +- > Lib/test/test_email/test_pickleable.py |57 + > Lib/test/test_email/test_policy.py | 126 +- > 16 files changed, 6994 insertions(+), 116 deletions(-) > > > diff --git a/Doc/library/email.policy.rst b/Doc/library/email.policy.rst > --- a/Doc/library/email.policy.rst > +++ b/Doc/library/email.policy.rst > @@ -306,3 +306,326 @@ >``7bit``, non-ascii binary data is CTE encoded using the > ``unknown-8bit`` >charset. Otherwise the original source header is used, with its > existing >line breaks and and any (RFC invalid) binary data it may contain. > + > + > +.. note:: > + > + The remainder of the classes documented below are included in the standard > + library on a :term:`provisional basis `. Backwards > + incompatible changes (up to and including removal of the feature) may > occur > + if deemed necessary by the core developers. > + > + > +.. class:: EmailPolicy(**kw) > + > + This concrete :class:`Policy` provides behavior that is intended to be > fully > + compliant with the current email RFCs. These include (but are not limited > + to) :rfc:`5322`, :rfc:`2047`, and the current MIME RFCs. > + > + This policy adds new header parsing and folding algorithms. Instead of > + simple strings, headers are custom objects with custom attributes > depending > + on the type of the field. The parsing and folding algorithm fully > implement > + :rfc:`2047` and :rfc:`5322`. > + > + In addition to the settable attributes listed above that apply to all > + policies, this policy adds the following additional attributes: > + > + .. attribute:: refold_source > + > + If the value for a header in the ``Message`` object originated from a > + :mod:`~email.parser` (as opposed to being set by a program), this > + attribute indicates whether or not a generator should refold that value > + when transforming the message back into stream form. The possible > values > + are: > + > + > === > + ``none`` all source values use original folding > + > + ``long`` source values that have any line that is longer than > +``max_line_length`` will be refolded > + > + ``all`` all values are refolded. > + > === > + > + The default is ``long``. > + > + .. attribute:: header_factory > + > + A callable that takes two arguments, ``name`` and ``value``, where > + ``name`` is a header field name and ``value`` is an unfolded header > field > + value, and returns a string-like object that represents that header. A > + default ``header_factory`` is provided that understands some of the > + :RFC:`5322` header field types. (Currently address fields and date > + fields have special treatment, while all other fields are treated as > + unstructured. This list will be completed before the extension is > marked > + stable.) > + > + The class provid
Re: [Python-Dev] cpython: Implemented PEP 405 (Python virtual environments).
On Sat, 26 May 2012 04:48:49 +0200
vinay.sajip wrote:
> +_sys_home = getattr(sys, '_home', None)
> +if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> +_sys_home = os.path.dirname(_sys_home)
What about pcbuild/amd64? Does this work on 64-bit builds?
> +_sys_home = getattr(sys, '_home', None)
> +if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> +_sys_home = os.path.dirname(_sys_home)
Same question here.
> +#!/usr/bin/env python
I don't think there should be a shebang line in a test file.
> +#
> +# Copyright 2011 by Vinay Sajip. All Rights Reserved.
> +#
> +# Permission to use, copy, modify, and distribute this software and its
> +# documentation for any purpose and without fee is hereby granted,
> +# provided that the above copyright notice appear in all copies and that
> +# both that copyright notice and this permission notice appear in
> +# supporting documentation, and that the name of Vinay Sajip
> +# not be used in advertising or publicity pertaining to distribution
> +# of the software without specific, written prior permission.
> +# VINAY SAJIP DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
> INCLUDING
> +# ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
> +# VINAY SAJIP BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
> +# ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER
> +# IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
> +# OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Why the copyright boilerplate?
> +# Use with a Python executable built from the Python fork at
> +#
> +# https://bitbucket.org/vinay.sajip/pythonv/ as follows:
This needs to be updated.
> +# You'll need an Internet connection (needed to download
> distribute_setup.py).
> +#
> +# The script will change to the environment's binary directory and run
> +#
> +# ./python distribute_setup.py
[...]
> +# This class will not be included in Python core; it's here for now to
Well... either the comment should be fixed or the class removed.
> +# XXX This option will be removed.
> +# XXX This will be changed to EnvBuilder
Same here.
> diff --git a/Lib/venv/scripts/nt/pysetup3.exe
> b/Lib/venv/scripts/nt/pysetup3.exe
> new file mode 100644
> index
> ..3f3c09ebc8e55f4ac3379041753cb34daef71892
> GIT binary patch
What's this file and how was it compiled?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: simplify and rewrite the zipimport part of 702009f3c0b1 a bit
On 05/25/2012 10:14 AM, Antoine Pitrou wrote: On Fri, 25 May 2012 18:57:57 +0200 Georg Brandl wrote: This is probably minor, but wouldn't it make more sense to have those constants uppercased? At least that's the general style we have in the codebase for enum values. +1, this surprised me too. FWIW I contributed the utime enum with the lowercase values. I don't uppercase enum values as a rule. Uppercasing preprocessor macros is a good idea because they're not safe. There are loads of ways they can produce unexpected behavior. So if something funny is going on, and the code involves some preprocessor slight-of-hand, those identifiers pop out at you and you know to double-check them. But enum values are as safe as houses. I think of them as equivalent to const ints, which I also don't uppercase. There's no need to draw attention to them. There's nothing in PEP 7 either way about enum nomenclature. But Benjamin has already uppercased these (and some other) enums, so I suppose the community has spoken. //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: PEP 421 is implemented.
On Sat, May 26, 2012 at 5:14 PM, georg.brandl wrote: > http://hg.python.org/peps/rev/cba34504163d > changeset: 4441:cba34504163d > user: Georg Brandl > date: Sat May 26 09:15:01 2012 +0200 > summary: > PEP 421 is implemented. Did you mean to move 405 instead? 421 is accepted, but not implemented yet. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to build a browser in Paython. cannot import webkit & object.
I think that I will make a browser in Official Python (not MacPorts Python). What should I do in order to install Webkit for Official Python (not MacPorts Python) ? from tokyo Japan. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build a browser in Paython. cannot import webkit & object.
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Sat, May 26, 2012 at 09:42:23PM +0900, "Mr.T Beppu" wrote: > I think that I will make a browser in Official Python (not MacPorts > Python). > What should I do in order to install Webkit for Official Python (not > MacPorts Python) ? Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: #12586: add provisional email policy with new header parsing and folding.
On Sat, 26 May 2012 09:14:07 +0200, Georg Brandl wrote: > Am 26.05.2012 00:44, schrieb r.david.murray: > > http://hg.python.org/cpython/rev/0189b9d2d6bc > > changeset: 77148:0189b9d2d6bc > > user:R David Murray > > date:Fri May 25 18:42:14 2012 -0400 > > summary: > > #12586: add provisional email policy with new header parsing and folding. [...] > > > > diff --git a/Doc/library/email.policy.rst b/Doc/library/email.policy.rst > > --- a/Doc/library/email.policy.rst > > +++ b/Doc/library/email.policy.rst > > @@ -306,3 +306,326 @@ > >``7bit``, non-ascii binary data is CTE encoded using the > > ``unknown-8bit`` > >charset. Otherwise the original source header is used, with its > > existing > >line breaks and and any (RFC invalid) binary data it may contain. [...] > > There's a lot of new stuff here: should have a versionadded? (Or do we need > new > markup for "provisional" stuff?) The entire policy module is new in 3.3 and has a versionadded at the top. New markup for provisional would be cool, though. I think eventually some of these docs will get factored out of policy, but that probably won't happen until it is no longer provisional. At that point I'll be doing a massive doc reorganization to deprecate many of the old APIs. Another option here is to consider 'policy' itself as the provisional package...except that to use it requires hooks in the other packages (the policy= keyword arguments). And I'm pretty satisfied with the API of the policy module itself, so I don't think it needs to be considered provisional. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: issue 14660: Implement PEP 420, namespace packages.
On Fri, May 25, 2012 at 10:41 AM, Barry Warsaw wrote:
> On May 25, 2012, at 10:31 AM, Brett Cannon wrote:
>
> >Is documentation coming in a separate commit?
>
> Yes. I've been reworking the import machinery documentation; it's a
> work-in-progress on the pep-420 feature clone ('importdocs' branch). I
> made
> some good progress and then got side-tracked, but I'm planning on getting
> back
> to it soon.
OK, great! Something to keep in the back of your head, Barry, is the naming
of importlib.find_loader(). Since its return value is not the same as what
the PEP introduces it might stand for a name change (it's new in Python 3.3
so it can be whatever makes sense).
Also just noticed that there is no update to importlib.abc.Finder for
find_loader(), which I assume is because of the hasattr() check in
PathFinder. That's fine, but it would be good to update the docs for ABC so
people know that is an optional interface they can implement.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal for better SSL errors
Hello,
In http://bugs.python.org/issue14837 I have attached a proof-of-concept
patch to improve the exceptions raised by the ssl module when OpenSSL
signals an error. The current situation is quite dismal, since you get
a sometimes cryptic error message with no viable opportunities for
programmatic introspection:
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> sock = socket.create_connection(("svn.python.org", 443))
>>> sock = ctx.wrap_socket(sock)
Traceback (most recent call last):
[...]
ssl.SSLError: [Errno 1] _ssl.c:420: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
SSLError instances only have a "errno" attribute which doesn't actually
contain a meaningful value.
With the posted patch, the above error becomes:
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> sock = socket.create_connection(("svn.python.org", 443))
>>> sock = ctx.wrap_socket(sock)
Traceback (most recent call last):
[...]
ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed (_ssl.c:494) [88296 refs]
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)
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).
To clarify a bit my request, I am asking for feedback on the principle
more than on the implementation right now.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Addressed some buildbot errors and comments on the checkin by Antoine on
On Sat, 26 May 2012 21:39:36 +0200
vinay.sajip wrote:
> return False
> _sys_home = getattr(sys, '_home', None)
> -if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> +if _sys_home and os.name == 'nt' and \
> +_sys_home.lower().endswith(('pcbuild', 'pcbuild\\amd64')):
> _sys_home = os.path.dirname(_sys_home)
Ok, but is one os.path.dirname() call enough in the AMD64 case? It
looks like you'd want to walk up two directories rather than one (but I
might misunderstand).
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for better SSL errors
On 5/26/2012 3:28 PM, Antoine Pitrou wrote:
Hello,
In http://bugs.python.org/issue14837 I have attached a proof-of-concept
patch to improve the exceptions raised by the ssl module when OpenSSL
signals an error. The current situation is quite dismal, since you get
a sometimes cryptic error message with no viable opportunities for
programmatic introspection:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.verify_mode = ssl.CERT_REQUIRED
sock = socket.create_connection(("svn.python.org", 443))
sock = ctx.wrap_socket(sock)
Traceback (most recent call last):
[...]
ssl.SSLError: [Errno 1] _ssl.c:420: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
I agree that this is not easy to read ;-)
SSLError instances only have a "errno" attribute which doesn't actually
contain a meaningful value.
With the posted patch, the above error becomes:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.verify_mode = ssl.CERT_REQUIRED
sock = socket.create_connection(("svn.python.org", 443))
sock = ctx.wrap_socket(sock)
Traceback (most recent call last):
[...]
ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed (_ssl.c:494) [88296 refs]
Repeating the same reason in upper and lower case is unhelpful noise.
Here is my suggested human-readable message.
ssl.SSLError: in ssl sublibrary, certificate verify failed
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'
Not being up on ssl sublibraries, I would tend to think that means the
main ssl library that gets imported. If that is wrong, .sublibrary would
be clearer to me, but knowledgable users may be fine with it as it is.
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)
Python is not a 'minimize characters written' language and library.
Inside an exception branch,
if e.reason == 'CERTIFICATE_VERIFY_FAILED':
is really clear, more so than any abbreviation.
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).
Given what you have written, I think the aim should be to get rid of it.
If you want to be conservative and not just delete it now, give SSLError
a __getattr__(self,name) method that looks for name == 'errno' and when
so, issues a DeprecationWarning "SSLError.errno is meaningless and will
be removed in the future. It is currently fixed at 0." before returning 0.
To clarify a bit my request, I am asking for feedback on the principle
more than on the implementation right now.
My view: better exception data is good. The exception class is useful
both to people and programs. The exception message is mainly for people
in tracebacks for uncaught exceptions. Other attributes are mainly for
programs that catch the exception and need more information than just
the class. Exceptions, like SSLErrors, reporting external conditions
that a program can respond to, are prime candidates for such attributes.
+1 to this enhancement.
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for better SSL errors
On Sat, 26 May 2012 17:44:08 -0400
Terry Reedy wrote:
> > Traceback (most recent call last):
> > [...]
> > ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> > verify failed (_ssl.c:494) [88296 refs]
>
> Repeating the same reason in upper and lower case is unhelpful noise.
> Here is my suggested human-readable message.
>
> ssl.SSLError: in ssl sublibrary, certificate verify failed
I should have made clearer that "certificate verify failed" is a
string returned by OpenSSL. In this case it's exactly similar to the
mnemonic, which might not always be the case (I honestly have not done
any research on this point). Also, the mnemonic is useful to know which
reason to test for, when seen in a traceback.
(here I'd draw a parallel with POSIX errnos, where it has been a common
request for years for OSError's str() to display the errno mnemonic,
such as e.g. ENOENT, rather than its number)
> e = sys.last_value
> e.library
> > 'SSL'
>
> Not being up on ssl sublibraries, I would tend to think that means the
> main ssl library that gets imported. If that is wrong, .sublibrary would
> be clearer to me, but knowledgable users may be fine with it as it is.
Well, it's called "library" in OpenSSL-speak, so I kept that name, but
I am not particularly attached to it, so "sublibrary" could work too.
As for what it means, "SSL" refers to the implementation of the SSL
network protocol (or TLS), while other OpenSSL "libraries" cater with
e.g. certificate management ("X509"), parsing of certificate files
("PEM"), etc.
> > 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).
>
> Given what you have written, I think the aim should be to get rid of it.
I also think it's desireable.
Thanks for sharing your opinion
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for better SSL errors
On 26May2012 21:28, Antoine Pitrou 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 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for better SSL errors
On Sat, May 26, 2012 at 12:28 PM, Antoine Pitrou wrote:
>
> Hello,
>
> In http://bugs.python.org/issue14837 I have attached a proof-of-concept
> patch to improve the exceptions raised by the ssl module when OpenSSL
> signals an error. The current situation is quite dismal, since you get
> a sometimes cryptic error message with no viable opportunities for
> programmatic introspection:
>
> >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
> >>> ctx.verify_mode = ssl.CERT_REQUIRED
> >>> sock = socket.create_connection(("svn.python.org", 443))
> >>> sock = ctx.wrap_socket(sock)
> Traceback (most recent call last):
> [...]
> ssl.SSLError: [Errno 1] _ssl.c:420: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
>
> SSLError instances only have a "errno" attribute which doesn't actually
> contain a meaningful value.
>
> With the posted patch, the above error becomes:
>
> >>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
> >>> ctx.verify_mode = ssl.CERT_REQUIRED
> >>> sock = socket.create_connection(("svn.python.org", 443))
> >>> sock = ctx.wrap_socket(sock)
> Traceback (most recent call last):
> [...]
> ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed (_ssl.c:494) [88296 refs]
>
>
> 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)
>
> 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).
>
>
> To clarify a bit my request, I am asking for feedback on the principle
> more than on the implementation right now.
>
+1 I like it. It is better than what we have today.
As for the misleading errno attribute, since it is not a posix errno I
think it could be hard wired to 0 for SSL errors if and only if openssl is
not actually setting it to something meaningful. The fact that an
exception was raised is the error and what the exception was about in the
case of SSL errors can come from your new library and reason attributes.
There is a long term caveat to the overall approach: It still leaves the
exception details being OpenSSL specific. If someone wants to ditch
OpenSSL and use something else such as NSS (for example) in a future _ssl
implementation what would its exception error info story look like?
I would go ahead with this work regardless. It improves on what we have
today. Defining a nicer way for SSL exceptions that is library agnostic is
a larger project that should be done independent of making what we have
today easier to work with.
-gps
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
