[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!
> > Also, in that same example, according to your specs, the TypeError
> > raised by bar() has the ZeroDivisionError raised
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
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 st
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:
On Mon, 16 May 2005, Guido van Rossum wrote:
> Here's a bunch of commentary:
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.
> You're not giving enough credit to Java, which has the "cause" part
> nailed IMO.
You're right. I missed that.
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.
Guido van Rossum wrote:
> 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
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 int
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 mail
But that could easily be fixed by appending the context to the end of
the chain, right?
On 5/17/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Consider
> >
> > try:
> > BLOCK
> > except EXCEPTION, VAR:
> > HANDLER
> >
> > I'd like to see this tr
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
At 07:41 AM 5/17/2005 -0700, 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
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 transl
[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 beca
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
[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?"
>
> Excl
On Mon, May 16, 2005 at 10:11:47PM -0400, Jack Diederich wrote:
> The values are never shared by expections of the class
^^
s/expect/except/
Exceptions are expected by except statements - and ispell can't tell the
difference.
-jackdied
___
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 doub
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 double-underscore, and I
> think that's precedent to be followed.
That i
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
[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 cre
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 th
22 matches
Mail list logo
