This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients draghuram, ncoghlan, pitrou, poke, steven.daprano
Date 2010-12-04.17:18:12
SpamBayes Score 9.47836e-07
Marked as misclassified No
Message-id <>
To get back to my original objection, it shouldn't be that difficult to differentiate between "__context__ never set" and "__context__ explicitly suppressed".

(e.g. using a property that sets an internal flag when set from Python code or via PyObject_SetAttr, or else a special ExceptionContextSuppressed singleton).

BaseException could then be given a "no_context" class method that did whatever dancing was necessary to suppress the context.

So Steven's examples would become:
def process(iterable):
        x = next(iterable)
    except StopIteration:
        raise ValueError.no_context("can't process empty iterable")

def func(x):
        x + 0
    except (ValueError, TypeError):
        raise MyException.no_context('x is not a number')

With appropriate changes to the exception display code, no_context could be as simple as the C equivalent of the following:

def no_context(cls, *args, **kwds):
  exc = cls(*args, **kwds)
  exc.__context__ = ExceptionContextSuppressed
  return exc

Another alternative would be an additional internal flag queried by the exception chaining code itself:

def no_context(cls, *args, **kwds):
  exc = cls(*args, **kwds)
  exc.__context__ = None
  exc._add_context = False
  return exc
Date User Action Args
2010-12-04 17:18:16ncoghlansetrecipients: + ncoghlan, pitrou, draghuram, steven.daprano, poke
2010-12-04 17:18:16ncoghlansetmessageid: <>
2010-12-04 17:18:12ncoghlanlinkissue6210 messages
2010-12-04 17:18:12ncoghlancreate