[Python-Dev] PEP 409 - final? (original) (raw)

Guido van Rossum guido at python.org
Wed Feb 1 21:07:06 CET 2012

On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman <ethan at stoneleaf.us> wrote:

Guido van Rossum wrote:

Hm... Reading this draft, I like the idea of using "raise X from None", but I still have one quibble. It seems the from clause sets cause, and cause can indicate three things: (1) print cause (explicitly set), (2) print context (default), (3) print neither (raise X from None). For (1), cause must of course be a traceback object. Actually, for (1) cause is an exception object, not a traceback.

Ah, sorry. I'm not as detail-oriented as I was. :-)

The PEP currently proposes to use two special values: False for (2), None for (3). To me, this has a pretty strong code smell, and I don't want this pattern to be enshrined in a PEP as an example for all to follow. (And I also don't like "do as I say, don't do as I do." :-)

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.

I suppose we could use True for (2) to indicate that context should be printed, leaving None for (3)... but having context at None and cause at True could certainly be confusing (the default case when no chaining is in effect).

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.

Can we think of a different special value to distinguish between (2) and (3)? Ideally one that doesn't change the nice "from None" idiom, which I actually like as a way to spell this.

How about this: Exception Life Cycle ==================== Stage 1 - brand new exception ----------------------------- raise ValueError() * context is None * cause is None Stage 2 - exception caught, exception raised -------------------------------------------- try: raise ValueError() except Exception: raise CustomError() * context is previous exception * cause is True Stage 3 - exception raised from [exception | None] -------------------------------------------------- try: raise ValueError() except Exception: raise CustomError() from [OtherException | None] * context is previous exception * cause is [OtherException | None]

No, this has the same code smell for me. See above.

Sorry that life isn't easier,

Where would be the fun without the challenge?

+1 :-)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list