while there is at least some interest in incorporating my
optimizations, response has still been low. I figure that the changes
are probably too much for a single big incorporation step. On a recent
flight, I thought about cutting it down to make it more easily
digestible. The basic idea is to remove the optimized interpreter
dispatch loop and advanced instruction format and use the existing
ones. Currently (rev. ca8a0dfb2176), opcode.h uses 109 of potentially
available 255 instructions using the current instruction format.
Hence, up to 149 instruction opcodes could be given to optimized
instruction derivatives. Consequently, a possible change would require
a) opcode.h to add new instruction opcodes,
b) ceval.c to include the new instruction opcodes in PyEval_EvalFrameEx,
c) abstract.c, object.c (possible other files) to add the
quickening/rewriting function calls.
If this is more interesting, I could start evaluating which
instruction opcodes should be allocated to which derivatives to get
the biggest benefit. This is a lot easier to implement (because I can
re-use the existing instruction implementations) and can easily be
made to be conditionally compile-able, similar to the computed-gotos
option. Since the changes are minimal it is also simpler to understand
and deal with for everybody else, too. On the "downside", however, not
all optimizations are possible and/or make sense in the given limit of
instructions (no data-object inlining and no reference-count
How does that sound?
Have a nice day,
I was looking at the other Open Issues on PEP 3134, think I might try to
resolve them as well, and discovered via testing that they have already
been taken care of.
Is there an established way to get information like that?
I realize that PEPs are partly historical documents, but it would it
make sense to add a note after an Open Issue (or any other section) that
was refined, resolved, or whatever in a later PEP or bug or patch or ...*
*Yes, I am volunteering to tackle that project.
It seems a number of people are interested that the Python trunk
switches to Visual Studio 2010 *now*. I've been hesitant to agree
to such a change, as I still hope that Python can skip over VS 2010
(a.k.a. VS 10), and go straight to VS 11.
However, I just learned that VS 11 supposed ready VS 10 project files
just fine, with no need of conversion.
So I'd be willing to agree to converting the Python trunk now. It
will surely cause all kinds of issues, as any switching of Visual Studio
releases has caused in the past.
Since a number of people have already started with such a project,
I'd like to ask for a volunteer who will lead this project. You
get the honor to commit the changes, and you will be in charge if
something breaks, hopefully finding out solutions in a timely manner
(not necessarily implementing the solutions yourself).
P.S. Here is my personal list of requirements and non-requirements:
- must continue to live in PCbuild, and must replace the VS 9
project files "for good"
- may or may not support automatic conversion to VS 9. If it turns
out that conversion to old project files is not feasible, we could
either decide to maintain old project files manually (in PC/VS9),
or just give up on maintaining build support for old VS releases.
- must generate binaries that run on Windows XP
- must support x86 and AMD64 builds
- must support debug and no-debug builds
- must support PGO builds
- must support buildbot
- must support building all extensions that we currently build
- may break existing buildbot installations until they upgrade to
a new VS release
- must support PCbuild/rt.bat
- should support Tools/msi. If it doesn't, I'll look into it.
- must nearly pass the test suite (i.e. number of additional failures
due to VS 2010 should be "small")
I'm looking at the docs to make the relevant changes due to PEP 409, and
I'm noticing some problems.
E.g. The PyException_Get|Set_Context|Cause all talk about using NULL to
clear the related attribute, when actually in should be Py_None.
Only PyException_GetCause is directly related to PEP 409 -- should I
only fix that one, and open up a new issue on the tracker for the other
three, or should I fix all four now?
Title: Suppressing exception context
Author: Ethan Furman <ethan(a)stoneleaf.us>
Type: Standards Track
Post-History: 30-Aug-2002, 01-Feb-2012
One of the open issues from PEP 3134 is suppressing context: currently
there is no way to do it. This PEP proposes one.
There are two basic ways to generate exceptions:
1) Python does it (buggy code, missing resources, ending loops, etc.)
2) manually (with a raise statement)
When writing libraries, or even just custom classes, it can become
necessary to raise exceptions; moreover it can be useful, even
necessary, to change from one exception to another. To take an example
from my dbf module::
value = int(value)
Whatever the original exception was (``ValueError``, ``TypeError``, or
something else) is irrelevant. The exception from this point on is a
``DbfError``, and the original exception is of no value. However, if
this exception is printed, we would currently see both.
Several possibilities have been put forth:
* ``raise as NewException()``
Reuses the ``as`` keyword; can be confusing since we are not really
reraising the originating exception
* ``raise NewException() from None``
Follows existing syntax of explicitly declaring the originating
* ``exc = NewException(); exc.__context__ = None; raise exc``
Very verbose way of the previous method
* ``raise NewException.no_context(...)``
Make context suppression a class method.
All of the above options will require changes to the core.
I proprose going with the second option::
raise NewException from None
It has the advantage of using the existing pattern of explicitly setting
raise KeyError() from NameError()
but because the 'cause' is ``None`` the previous context, while retained,
is not displayed by the default exception printing routines.
Currently, ``__context__`` and ``__cause__`` start out as None, and then get
set as exceptions occur.
To support ``from None``, ``__context__`` will stay as it is, but
``__cause__`` will start out as ``False``, and will change to ``None``
when the ``raise ... from None`` method is used.
The default exception printing routine will then:
* If ``__cause__`` is ``False`` the ``__context__`` (if any) will be
* If ``__cause__`` is ``None`` the ``__context__`` will not be printed.
* if ``__cause__`` is anything else, ``__cause__`` will be printed.
This has the benefit of leaving the ``__context__`` intact for future
logging, querying, etc., while suppressing its display if it is not caught.
This is important for those times when trying to debug poorly written
libraries with `bad error messages`_.
There is a patch for CPython implementing this attached to `Issue 6210`_.
Discussion and refinements in this `thread on python-dev`_.
.. _bad error messages: http://bugs.python.org/msg152294
.. _Issue 6210: http://bugs.python.org/issue6210
.. _thread on python-dev:
This document has been placed in the public domain.