RetroSearch Browse

Sat Mar 3 00:45:20 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-March/071464.html

On 2/26/07, Andrew Dalke <dalke at dalkescientific.com> 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?

Collin Winter

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-March/071464.html below:

[Python-Dev] PEP 344 (was: with_traceback)