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
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
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
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
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/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 3/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > You start with a traceback object pointing to the current frame
> > object (traceback objects are distinct from frame objects,
>
> Just out of curiosity, is it really necessary to have
> a distinct traceback object? Coul
Guido van Rossum wrote:
> You start with a traceback object pointing to the current frame
> object (traceback objects are distinct from frame objects,
Just out of curiosity, is it really necessary to have
a distinct traceback object? Couldn't the traceback
just be made of dead frame objects linked
[Summary: James Knight's idea can't work unless we copy the entire
stack, which is bad. Disregard my previous posts in this thread of a
few minutes ago. See the end of this post why.]
On 3/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> James Y Knight wrote:
>
> > It seems to me that a stack trace s
On 2/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >I am beginning to think that there are serious problems with attaching
> >the traceback to the exception; I really don't like the answer that
> >pre-cre
On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote:
> > I am beginning to think that there are serious problems with attaching
> > the traceback to the exception; I really don't like the answer that
> > pre-creating an exception is unpythonic
On Mar 1, 2007, at 3:27 AM, Greg Ewing wrote:
> James Y Knight wrote:
>> The traceback won't necessarily be *useful*,
>
> Almost completely use*less*, I would have thought.
> The traceback is mostly used to find out where
> something went wrong, not where it went right (i.e.
> successful creation
[EMAIL PROTECTED] wrote:
> Perhaps the use-cases for attaching the traceback object
> to the exception would be better satisfied by simply having
> sys.exc_info() return an object with methods like Failure?
> I can't think of a good name for the new object type,
Maybe we could call it a 'catch'
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 traceback clobbered by
another thread raising
James Y Knight wrote:
> It seems to me that a stack trace should always be attached to an
> exception object at creation time
Um. Yes. Well, that's certainly an innovative solution...
> The traceback won't necessarily be *useful*,
Almost completely use*less*, I would have thought.
The traceba
On Wed, 28 Feb 2007 18:10:21 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I am beginning to think that there are serious problems with attaching
>the traceback to the exception; I really don't like the answer that
>pre-creating an exception is unpythonic in Py3k.
In Twisted, to deal with a
Andrew Dalke wrote:
> On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
>
>> It seems to me that a stack trace should always be attached to an
>> exception object at creation time of the exception, and never at any
>> other time.
Sounds good in principle - but don't forget that normally the
On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> It seems to me that a stack trace should always be attached to an
> exception object at creation time of the exception, and never at any
> other time. Then, if someone pre-creates an exception object, they
> get consistent and easily explainab
On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote:
> I am beginning to think that there are serious problems with attaching
> the traceback to the exception; I really don't like the answer that
> pre-creating an exception is unpythonic in Py3k.
I'll say up front that I haven't been paying as muc
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > How plausible would it be to optimize all exception instantiation?
> > Perhaps use slots and a freelist for everything inheriting from
> > BaseException and not inheriting from other builtin types?
>
> I'm not sure a free l
Adam Olsen wrote:
> How plausible would it be to optimize all exception instantiation?
> Perhaps use slots and a freelist for everything inheriting from
> BaseException and not inheriting from other builtin types?
I'm not sure a free list would help much for instances
of user define classes, sinc
Jean-Paul Calderone wrote:
> And the new behavior? Every raise statement copies an exception instance,
> some code will create a new exception instance for each raise statement,
> some code will create a single exception and re-raise it repeatedly.
Make that "most code will create a new exceptio
On 2/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I am beginning to think that there are serious problems with attaching
> the traceback to the exception; I really don't like the answer that
> pre-creating an exception is unpythonic in Py3k.
How plausible would it be to optimize all except
Adam Olsen wrote:
> Exceptions aren't arbitrary objects though. The requirement that they
> inherit from BaseException is specifically to create a common
> interface.
But that doesn't tell you enough. If the exception
references some other object, should you copy it?
You can't tell just from the
I am beginning to think that there are serious problems with attaching
the traceback to the exception; I really don't like the answer that
pre-creating an exception is unpythonic in Py3k.
On 2/28/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <[
On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <[EMAIL PROTECTED]> wrote:
>On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Adam Olsen wrote:
>>
>> > It sounds like we should always copy the exception given to raise,
>>
>> I don't like that either, for all the reasons that
>> make it infeasible
On 2/28/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>
> > It sounds like we should always copy the exception given to raise,
>
> I don't like that either, for all the reasons that
> make it infeasible to copy an arbitrary object in a
> general way.
Exceptions aren't arbitrary obj
Adam Olsen wrote:
> It sounds like we should always copy the exception given to raise,
I don't like that either, for all the reasons that
make it infeasible to copy an arbitrary object in a
general way.
--
Greg
___
Python-Dev mailing list
Python-Dev@p
[EMAIL PROTECTED] wrote:
> Or modify __new__ on your particular heavily-optimized
> exception to have a free-list,
Doing that in Python is likely to have as much overhead as
creating an instance.
The simple and obvious optimisation is to pre-create the
instance, but we're proposing to make the o
On 2/26/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
> >
> > > NO_END_OF_RECORD = ParserError("Cannot find end of record")
> >
> > Then don't do that, as it's bad style for Python 3.x. ;-)
>
> I don't like that answer. I can
On Feb 28, 2007, at 1:50 AM, Andrew Dalke wrote:
> Glyph:
>> This seems like kind of a strange micro-optimization to have an
>> impact
>> on a language change discussion.
>
> Just as a reminder, my concern is that people reuse exceptions
> (rarely)
> and that the behavior of the "with_excepti
On 2/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> >I don't like that answer. I can think of legitimate
> >reasons for wanting to pre-create exceptions, e.g. if
> >I'm intending to raise and catch a particular exc
Glyph:
> This seems like kind of a strange micro-optimization to have an impact
> on a language change discussion.
Just as a reminder, my concern is that people reuse exceptions (rarely)
and that the behavior of the "with_exceptions()" method is ambiguous
when that happens. It has nothing to do w
On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>I don't like that answer. I can think of legitimate
>reasons for wanting to pre-create exceptions, e.g. if
>I'm intending to raise and catch a particular exception
>frequently and I don't want the overhead of creating
>a ne
PJE:
> Then don't do that, as it's bad style for Python 3.x. ;-)
It's bad style for 3.x only if Python goes with this interface. If
it stays with the 2.x style then there's no problem. There
may also be solutions which are cleaner and which don't
mutate the exception instance.
I am not proposi
Phillip J. Eby wrote:
> At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
>
> > NO_END_OF_RECORD = ParserError("Cannot find end of record")
>
> Then don't do that, as it's bad style for Python 3.x. ;-)
I don't like that answer. I can think of legitimate
reasons for wanting to pre-create exceptions
At 03:38 PM 2/26/2007 -0700, Andrew Dalke wrote:
>Guido's talk at PyCon said:
>
> > Use raise E(arg).with_traceback(tb)
> > instead of raise E, arg, tb
>
>That seems strange to me because of the mutability. Looking through
>the back discussions on this list I see Guido commented:
> http://m
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
...
FWIW, you can
Guido's talk at PyCon said:
> Use raise E(arg).with_traceback(tb)
> instead of raise E, arg, tb
That seems strange to me because of the mutability. Looking through
the back discussions on this list I see Guido commented:
http://mail.python.org/pipermail/python-3000/2007-February/005689.ht
39 matches
Mail list logo
