Guido van Rossum wrote:
> Perhaps we could allow reraising whenever the
> existing traceback chain contains a reference to a frame that is an
> ancestor of (or equal to) the newly raising frame?
This is starting to sound terribly hairy.
Would it help if a different syntax were used for
raising an
Guido van Rossum wrote:
> But what's the advantage of not instantiating the exception if we
> instantiate the context instead?
Probably not much. But most control-flow-exception
catching will just be 'except E:' in which case
you don't need to instantiate anything. (Assuming
we get rid of traceba
On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I'm afraid we're back at square zero; perhaps we should keep the
> > existing (type, value, traceback) API
>
> Whatever happens, we should be able to get that down
> to at most two things: (exception, context) where
>
On 3/2/07, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> On 3/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > So, despite the existence of libraries that pre-create exceptions, how
> > bad would it really be if we declared that use unsafe? It wouldn't be
> > hard to add some kind of boobytrap tha
Personally, +1 for new attributes, -1 for more syntax, +0 for making
it bad style to pre-create exceptions. One object should have all you
need.
On 3/2/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > [snip..]
> > The one thing that makes me not want to give up yet is tha
Guido van Rossum wrote:
> I'm afraid we're back at square zero; perhaps we should keep the
> existing (type, value, traceback) API
Whatever happens, we should be able to get that down
to at most two things: (exception, context) where
exception is either a class or an instance, and
context include
On 3/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So, despite the existence of libraries that pre-create exceptions, how
> bad would it really be if we declared that use unsafe? It wouldn't be
> hard to add some kind of boobytrap that goes off when pre-created
> exceptions are raised multipl
Guido van Rossum wrote:
> [snip..]
> The one thing that makes me not want to give up yet is that having the
> traceback, context, cause etc. as attributes of the exception object
> would seem to make the API for handling exceptions that much cleaner,
> compared to having to call sys.exc_info() or e
On 3/2/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 2/26/07, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> > My concern when I saw Guido's keynote was the worry that
> > people do/might write code like this
> >
> > NO_END_OF_RECORD = ParserError("Cannot find end of record")
> >
> > def parse_recor
Collin Winter wrote:
> Do those who oppose __traceback__ also oppose __cause__ and
> __context__?
They would seem to have the same problems. Whatever
solution is adopted for the traceback should probably
be applied to them as well, perhaps by generalising
the traceback into an "exception context"
On 2/26/07, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> My concern when I saw Guido's keynote was the worry that
> people do/might write code like this
>
> NO_END_OF_RECORD = ParserError("Cannot find end of record")
>
> def parse_record(input_file):
>...
> raise NO_END_OF_RECORD
>...
>
>
James Knight writes:
> I still don't see why people think the python interpreter should be
> automatically providing __context__. To me it seems like it'll just
> clutter things up for no good reason. If you really want the other
> exception, you can access it via the local variable in the frame
>
On Sat, 21 May 2005, James Y Knight wrote:
> On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
> > This only helps if you can get to a debugger. What if you're
> > reading your web server's error log?
>
> Then you're in trouble anyways because you need the contents of some
> local to figure out w
On May 20, 2005, at 6:37 PM, Phillip J. Eby wrote:
> This only helps if you can get to a debugger. What if you're
> reading your web server's error log?
Then you're in trouble anyways because you need the contents of some
local to figure out what's going on, also.
James
_
On May 20, 2005, at 4:31 AM, Ka-Ping Yee wrote:
> Guido van Rossum wrote:
>
>> Do we really need both __context__ and __cause__?
>>
>
> Well, it depends whose needs we're trying to meet.
>
> If we want to satisfy those who have been asking for chaining
> of unexpected secondary exceptions, then w
[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
[Guido van Rossum]
> > Do we really need both __context__ and __cause__?
[Ka-Ping Yee]
> Well, it depends whose needs we're trying to meet.
>
> If we want to satisfy those who have been asking for chaining
> of unexpected secondary exceptions, then we have to provide that
> on some attribute.
>
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 Fri, 20 May 2005, Ka-Ping Yee wrote:
> Can be back up and see if we can agree on a specification at a semantic
> level first? I've been trying to narrow down exactly what you seem to
> intuitively want -- how do you like the following:
>
>Definition of "context": An exception-raise event X
Guido van Rossum wrote:
> Do we really need both __context__ and __cause__?
Well, it depends whose needs we're trying to meet.
If we want to satisfy those who have been asking for chaining
of unexpected secondary exceptions, then we have to provide that
on some attribute.
If we also want to prov
Guido van Rossum wrote:
> 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:
>
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
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 applications for chaining mentioned in
these discussion
42 matches
Mail list logo
