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 traceback
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
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 traceback
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 isn't
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 current situation
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 traceback
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
[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'
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 in
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-creating an
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_exceptions()
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 think of
[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
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
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 exception
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 exception
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, since
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 list would
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 much
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 explainable
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 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
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 new
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:
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
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:
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, e.g.
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
28 matches
Mail list logo
