Guido van Rossum wrote:
> On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> My apologies for my ignorance, but is the code smell because both False and
>> None evaluate to bool(False)?
>
> That's part of it, but the other part is that the type of __context__
> is now truly dynamic. I often *think* of variables as having some
> static type, e.g. "integer" or "Foo instance", and for most Foo
> instances I consider None an acceptable value (since that's how
> pointer types work in most static languages). But the type of
> __context__ you're proposing is now a union of exception and bool,
> except that the bool can only be False.
>
> It seems you really need a marker object. I'd be fine with using some
> other opaque marker -- IMO that's much better than using False but
> disallowing True.
So for __cause__ we need three values:
1) Not set special value (prints __context__ if present)
2) Some exception (print instead of __context__)
3) Ignore __context__ special value (and stop following the
__context__ chain)
For (3) we're hoping for None, for (2) we have an actual exception, and
for (1) -- hmmm.
It seems like a stretch, but we could do (looking at both __context__
and __cause__):
__context__ __cause__
raise None False [1]
reraise previous True [2]
reraise from previous None [3] | exception
[1] False means non-chained exception
[2] True means chained exception
[3] None means chained exception, but by default we do not print
nor follow the chain
The downside to this is that effectively either False and True mean the
same thing, i.e. try to follow the __context__ chain, or False and None
mean the same thing, i.e. don't bother trying to follow the __context__
chain because it either doesn't exist or is being suppressed.
Feels like a bunch of complexity for marginal value. As you were
saying, some other object to replace both False and True in the above
table would be ideal.
~Ethan~