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_record(input_file):
> > ...
> > raise NO_END_OF_RECORD
> > ...
> >
> >
> > That is, create instances at the top of the module, to be used
> > later. This code assume that the NO_END_OF_RECORD
> > exception instance is never modified.
> >
> > If the traceback is added to its __traceback__ attribute then
> > I see two problems if I were to write code like the above:
> >
> > - the traceback stays around "forever"
> > - the code is no longer thread-safe.
>
> While there are now quite a few threads discussing the problems
> related to the proposed __traceback__ attribute (thread-safety being
> the primary one, from what I can tease out), I haven't seen anyone
> address the rest of PEP 344: the __cause__ and __context__ attributes.
>
> Do those who oppose __traceback__ also oppose __cause__ and
> __context__? Should PEP 344 be rejected on these grounds, or should we
> just learn not to pre-instance exceptions if we're interested in these
> attributes?
Those attributes have exactly the same problems as __traceback__. They
exist mostly to save the butt of those folks who didn't even know they
had a problem, so I don't think that saying "if you want this
functionality, don't do X" is very helpful.
I'm afraid we're back at square zero; perhaps we should keep the
existing (type, value, traceback) API rather than going for radical
(and unproven) innovation like "except E as v with tb: <block>". In
the future we will still have the path open to a "Catch" object as
proposed by Glyph and Greg; all we'd have to do is give the Catch
object sequence semantics during the transition.
I wonder if we should also roll back the new semantics of "except E as
v: <block>" of deleting v when exiting <block>; that was proposed in
anticipation of the traceback attribute on exceptions. If we're not
doing that, using vanilla variable semantics will give better
migration from 2.6 and fewer surprises.
On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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" object
> that can hold other info.
That would work for the "Catch" object. It wouldn't work so well for
the original (t, v, tb) API, nor for the "except E as v with tb"
syntax ("except E as v with tb in context for cause" anyone? :-)
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 even "except E as v with
tb".
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 multiple times. If this had always been the
semantics I'm sure nobody would have complained and I doubt that it
would have been a common pitfall either (since if it doesn't work,
there's no bad code abusing it, and so there are no bad examples that
newbies could unwittingly emulate).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
