Ka-Ping Yee wrote:
[...]
(a) ban string exceptions
(b) require all exceptions to derive from Exception
(c) ban bare except:
(d) eliminate sys.exc_*
I think somewhere in this list should be:
(?) Remove string exceptions from the Python stdlib
and perhaps:
(?)
Michael Hudson wrote:
Walter Dörwald [EMAIL PROTECTED] writes:
Ka-Ping Yee wrote:
[...]
(a) ban string exceptions
(b) require all exceptions to derive from Exception
(c) ban bare except:
(d) eliminate sys.exc_*
I think somewhere in this list should be:
(?) Remove
[Guido]
Here's a bunch of commentary:
[Ping]
Thanks. Sorry it's taken me a couple of days to get back to this.
I think i'm caught up on the mail now.
No problem!
snip
Also, in that same example, according to your specs, the TypeError
raised by bar() has the ZeroDivisionError raised in
On Monday 16 May 2005 22:41, Ka-Ping Yee wrote:
http://www.python.org/peps/pep-0344.html
| 2. Whenever an exception is raised, if the exception instance does
| not already have a '__context__' attribute, the interpreter sets
| it equal to the thread's exception context.
Here's another rule-of-thumb: when the VM and the user *share* the
attribute space of an object, the VM uses system attributes; the VM
uses plain attributes for objects that it owns completely (like code
objects, frames and so on, which rarely figure user code except for
the explicit purpose of
On Mon, May 16, 2005, Guido van Rossum wrote:
My rule has more to do with who owns the namespace on the one hand,
and with magic behavior caused (or indicated) by the presence of the
attribute on the other. Class or instance is irrelevant; that most
magic attributes live on classes or modules
[Guido van Rossum]
My rule has more to do with who owns the namespace on the one hand,
and with magic behavior caused (or indicated) by the presence of the
attribute on the other. Class or instance is irrelevant; that most
magic attributes live on classes or modules is just because those
I figured out the semantics that I'd like to see intuitively for
setting the context. I'm not saying this is all that reasonable, but
I'd like throw it out anyway to see what responses it gets.
Consider
try:
BLOCK
except EXCEPTION, VAR:
HANDLER
I'd like to see this
Guido van Rossum wrote:
Consider
try:
BLOCK
except EXCEPTION, VAR:
HANDLER
I'd like to see this translated into
try:
BLOCK
except EXCEPTION, VAR:
__context = VAR
try:
HANDLER
except Exception, __error:
Guido van Rossum wrote:
Unfortunately I can't quite decide whether either rule applies in the
case of exceptions.
I think you'd at least be justified in using the magic rule,
since they're set by the exception machinery.
Greg
___
Python-Dev mailing
On Mon, May 16, 2005, Ka-Ping Yee wrote:
This PEP is a concrete proposal for exception chaining, to follow
up on its mention here on Python-Dev last week as well as earlier
discussions in the past year or two.
http://www.python.org/peps/pep-0344.html
I've tried to summarize the
[Ka-Ping Yee]
This PEP is a concrete proposal for exception chaining, to follow
up on its mention here on Python-Dev last week as well as earlier
discussions in the past year or two.
http://www.python.org/peps/pep-0344.html
Here's a bunch of commentary:
You're not giving enough credit
Guido van Rossum wrote:
[SNIP - bunch of points from Guido]
Do we really need both __context__ and __cause__? Methinks that you
only ever need one: either you explicitly chain a new exception to a
cause, and then the context is probably the same or irrelevant, or you
don't explicitly chain,
On Mon, May 16, 2005 at 08:09:54PM -0500, Ka-Ping Yee wrote:
On Mon, 16 May 2005, Aahz wrote:
I'll comment here in hopes of staving off responses from multiple
people: I don't think these should be double-underscore attributes. The
currently undocumented ``args`` attribute isn't
[Jack Diederich]
I prefer trichomomies over dichotomies, but whether single or double
underscores are the bad or the ugly I'll leave to others. In python
double underscores can only mean I don't handle this, my class does or
I'm a C++ weenie, can I pretend this is private?
Excluding the
15 matches
Mail list logo
