On 3/2/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> We can get more than half of the benefit simply by using a default
> __init__ rather than a python one. If you need custom attributes but
> they're predefined you could subclass the exception and have them as
> class attributes. Given that, is th
Often people build mental models of performance that have little
bearing on reality. Thanks for measuring!
On 3/2/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> $ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception): pass'
> 'try: raise Foo()' 'except: pass'
> 100 loops, best of 10: 2.49
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
$ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception): pass'
'try: raise Foo()' 'except: pass'
100 loops, best of 10: 2.49 usec per loop
$ python2.5 -m timeit -r 10 -n 100 -s 'class Foo(Exception):' -s '
def __init__(self): pass' 'try: raise Foo()' 'except: pass'
100 loops, b
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
Michael Foord wrote:
> Um... except that the new attributes *obviously* means that the
> traceback information is obviously not going to work where you reuse a
> single instance and to expect otherwise seems naive.
Yes, but this means that the __traceback__ attribute
couldn't be *the* way of ha
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
Greg Ewing wrote:
> Michael Foord wrote:
>
>> Greg Ewing wrote:
>>
>>
>>> An exception caught and raised in one thread would
>>> be vulnerable to having its traceback clobbered by
>>> another thread raising the same instance.
>>>
>> Right - but that would still be *no worse* than the
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
Martin v. Löwis wrote:
> The style-guide in C is that macro names are spelled in all-caps, so
> if you see an all-caps identifier, you expect it to be a macro name.
Hi Martin.
OK, so somewhere we have:
/* NOARGS_NULL: A parameter declared in this way is present only because
* the function is r
Michael Foord wrote:
> Greg Ewing wrote:
>
> > An exception caught and raised in one thread would
> > be vulnerable to having its traceback clobbered by
> > another thread raising the same instance.
>
> Right - but that would still be *no worse* than the current situation
> where that information
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, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > This has given me another idea:
>...
> > Now, I'm not proposing that the raise statement should
> > actually have the above syntax -- that really would be
> > a step backwards. Instead it w
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
Greg Ewing wrote:
> Michael Foord wrote:
>
>> With the
>> proposed changes, modules that do this would *continue* to work, surely
>> ?
>>
>
> Probably, but it might mean they were no longer thread
> safe. An exception caught and raised in one thread would
> be vulnerable to having its tra
On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> This has given me another idea:
...
> Now, I'm not proposing that the raise statement should
> actually have the above syntax -- that really would be
> a step backwards. Instead it would be required to have
> one of the following forms:
>
>
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"
[EMAIL PROTECTED] wrote:
> Why not just allow both exception classes and exception instances to be
> raised, and only instantiate-at-catch in the case of a raise of a class
> and a catch with an "as" clause?
Because that doesn't solve the problem of pre-instantiated
exceptions. What I'm proposing
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
>...
>
>
On 3/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Since by far the most common use case is to create the
> exception in the raise statement, the behavior there won't be any
> different than it is today; the traceback on precreated objects will
> be useless, but folks who precreate them for p
On Sat, Mar 03, 2007 at 11:00:53AM +1300, Greg Ewing wrote:
> Now, I'm not proposing that the raise statement should
> actually have the above syntax -- that really would be
> a step backwards. Instead it would be required to have
> one of the following forms:
>
> raise ExceptionClass
>
> or
Proposal changed from "err, tb" to "err with tb" at Brett's good suggestion.
The rest of this message is a bit of a sidetrack; skimmers can stop now.
Nick Maclaren wrote:
>"Jim Jewett" wrote:
>> Guido van Rossum wrote:
>> > [multiple threads => don't share] whatever object
>> > contains the he
Nick Maclaren wrote:
> The instance contains all of the information about the details, such
> as the exact operation, the values and the context (including the
> traceback). It CAN'T be an object, because it is not 'assignable'
> (i.e. a value) - it is inherently bound to its context. You can
>
Brett Cannon wrote:
> except Exception as exc with tb:
> ...
I was thinking of that too, plus a matching
raise Exception with tb
The only use for a 'catch' object would then be for
returning from sys.exc_info(), and I'm not sure it's
worth creating one just for that rather than using
a
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Since this can conceivably be going on in parallel in multiple
> > threads, we really don't ever want to be sharing whatever object
> > contains the head of the chain of tracebacks since it mutates at every
> > frame bubble-up
On 3/2/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Since this can conceivably be going on in parallel in multiple
> > threads, we really don't ever want to be sharing whatever object
> > contains the head of the chain of tracebacks since it mutates at every
> > frame b
Guido van Rossum wrote:
> Since this can conceivably be going on in parallel in multiple
> threads, we really don't ever want to be sharing whatever object
> contains the head of the chain of tracebacks since it mutates at every
> frame bubble-up.
So (full) exceptions can't be unitary objects.
I
Sorry about a second message, but I mentioned this aspect earlier,
and it is semi-independent.
If I want to produce statistics, such as the times spent in various
operations, I need a callback when the class is disposed of. Now,
that WOULD be inconvenient to use the C object attribute callback,
u
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> Can you explain the reason for cleaning up in this scenario? Are you
> rapidly creating and destroying temporary class objects? Why can't you
> rely on the regular garbage collection process? Or does you class
> create an external resource like a te
32 matches
Mail list logo
