[Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
So, I'm currently trying to fix the regression in handling __class__ references in 3.3. The first step in this is unwinding the name change for the closure reference so it goes back to using "__class__" (instead of "@__class__") before finding a different way to fix #12370. As near as I can tell, my efforts are getting killed by the frozen instance of importlib: if I make the change in the straightforward fashion, the frozen copy of FindLoader.load_module() uses zero-argument super(), which tries to look up "@__class__", which fails, which means initialisation goes pear-shaped. I'm going to fix it in this case by tweaking importlib._bootstrap to avoid using zero-argument super() (with an unmodified core) before applying the changes, but yeah, be warned that you're in for some fun when tinkering with any construct used by importlib._bootstrap and end up doing something that involves changing the PYC magic number. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
2012/5/27 Nick Coghlan : > So, I'm currently trying to fix the regression in handling __class__ > references in 3.3. The first step in this is unwinding the name change > for the closure reference so it goes back to using "__class__" > (instead of "@__class__") before finding a different way to fix > #12370. > > As near as I can tell, my efforts are getting killed by the frozen > instance of importlib: if I make the change in the straightforward > fashion, the frozen copy of FindLoader.load_module() uses > zero-argument super(), which tries to look up "@__class__", which > fails, which means initialisation goes pear-shaped. > > I'm going to fix it in this case by tweaking importlib._bootstrap to > avoid using zero-argument super() (with an unmodified core) before > applying the changes, but yeah, be warned that you're in for some fun > when tinkering with any construct used by importlib._bootstrap and end > up doing something that involves changing the PYC magic number. Nasty! Perhaps freeze_importlib.py could be rewritten in C, so importlib could be recompiled when the compiler changes? -- Regards, Benjamin ___ 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
Re: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
Nasty! Perhaps freeze_importlib.py could be rewritten in C, so importlib could be recompiled when the compiler changes? Or we support bootstrapping from the source file, e.g. with an environment variable BOOTSTRAP_PY which points to the _bootstrap.py source. Regards, Martin ___ 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
Re: [Python-Dev] Proposal for better SSL errors
On Sat, 26 May 2012 19:31:55 -0700 "Gregory P. Smith" wrote: > > 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? That's a general issue with the ssl module. Unless we come up with our own API and abstraction layer (which has a cost in design effort and risks), we're following the OpenSSL architecture (e.g. the SSLContext idea). Regards Antoine. ___ 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
Re: [Python-Dev] Proposal for better SSL errors
On Sun, 27 May 2012 12:00:57 +1000
Cameron Simpson wrote:
> 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).
OpenSSL has a diversity of error codes. In this case there's the result
code returned by OpenSSL's SSL_get_error(), which is 1 (SSL_ERROR_SSL)
and is already recorded as "errno" (see below). There's the reason,
as returned by OpenSSL's ERR_get_reason(), which is
SSL_R_CERTIFICATE_VERIFY_FAILED. And I'm sure other oddities are
lurking.
> | 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.
That's a nice coincidence, but it's actually an OpenSSL-specific code.
Also, there's a bug in the current patch, the right value should be 1
(SSL_ERROR_SSL) not 5.
That said, I remember there's legacy code doing things like:
except SSLError as e:
if e.args[0] == SSL_ERROR_WANT_READ: ...
so we can't ditch the errno, although in 3.3 you would write:
except SSLWantReadError: ...
Regards
Antoine.
___
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
Re: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
Am 27.05.2012 09:43, schrieb Nick Coghlan: > So, I'm currently trying to fix the regression in handling __class__ > references in 3.3. The first step in this is unwinding the name change > for the closure reference so it goes back to using "__class__" > (instead of "@__class__") before finding a different way to fix > #12370. > > As near as I can tell, my efforts are getting killed by the frozen > instance of importlib: if I make the change in the straightforward > fashion, the frozen copy of FindLoader.load_module() uses > zero-argument super(), which tries to look up "@__class__", which > fails, which means initialisation goes pear-shaped. > > I'm going to fix it in this case by tweaking importlib._bootstrap to > avoid using zero-argument super() (with an unmodified core) before > applying the changes, but yeah, be warned that you're in for some fun > when tinkering with any construct used by importlib._bootstrap and end > up doing something that involves changing the PYC magic number. I hate to say it, but: I told y'all so :) http://mail.python.org/pipermail/python-dev/2012-April/118790.html Georg ___ 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
Re: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
On Sun, 27 May 2012 10:13:17 +0200 mar...@v.loewis.de wrote: > > Nasty! Perhaps freeze_importlib.py could be rewritten in C, so > > importlib could be recompiled when the compiler changes? > > Or we support bootstrapping from the source file, e.g. with an > environment variable BOOTSTRAP_PY which points to the _bootstrap.py > source. I've opened http://bugs.python.org/issue14928 and made it a release blocker. Regards Antoine. ___ 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
Re: [Python-Dev] Proposal for better SSL errors
On 27May2012 11:29, Antoine Pitrou wrote:
| On Sun, 27 May 2012 12:00:57 +1000
| Cameron Simpson wrote:
| > On 26May2012 21:28, Antoine Pitrou wrote:
| > | 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.
|
| That's a nice coincidence, but it's actually an OpenSSL-specific code.
Oh.
--
Cameron Simpson DoD#743
http://www.cskk.ezoshosting.com/cs/
Do not taunt Happy Fun Coder.
___
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
Re: [Python-Dev] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
Am 28.05.2012 03:55, schrieb terry.reedy: > http://hg.python.org/cpython/rev/4a7582866735 > changeset: 77195:4a7582866735 > branch: 3.2 > parent: 77189:6737c2ca98ee > user:Terry Jan Reedy > date:Sun May 27 21:29:17 2012 -0400 > summary: > Issue12510: Attempting to get invalid tooltip no longer closes Idle. > Original patch by Roger Serwy. > > files: > Lib/idlelib/CallTips.py | 9 ++--- > Misc/NEWS | 3 +++ > 2 files changed, 9 insertions(+), 3 deletions(-) > > > diff --git a/Lib/idlelib/CallTips.py b/Lib/idlelib/CallTips.py > --- a/Lib/idlelib/CallTips.py > +++ b/Lib/idlelib/CallTips.py > @@ -110,7 +110,9 @@ > namespace.update(__main__.__dict__) > try: > return eval(name, namespace) > -except (NameError, AttributeError): > +# any exception is possible if evalfuncs True in open_calltip > +# at least Syntax, Name, Attribute, Index, and Key E. if not Is something missing here? The comment text seems cut off. > +except: > return None "except Exception" may be better here. Georg ___ 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
