[Python-Dev] Exception Reorg PEP revised yet again

[Raymond Hettinger]

[Brett Cannon]  
> At this point the only
> changes to the hierarchy are the addition of BaseException and
> TerminatingException, and the change of inheritnace for
> KeyboardInterrupt, SystemExit, and NotImplementedError.  

TerminatingException
--------------------

The rationale for adding TerminatingException needs to be developed or
reconsidered.  AFAICT, there hasn't been an exploration of existing code
bases to determine that there is going to be even minimal use of "except
TerminatingException".

Are KeyboardInterrupt and SystemExit often caught together on the same
line and handled in the same way?  

If so, isn't "except TerminatingException" less explicit, clear, and
flexible than "except (KeyboardInterrupt, SystemExit)"?  Do we need a
second way to do it?

Doesn't the new meaning of Exception already offer a better idiom:

   try:
      suite()
   except Exception:
      log_or_recover()
   except:
      handle_terminating_exceptions()
   else:

Are there any benefits sufficient to warrant yet another new built-in?
Does it also warrant violating FIBTN by introducing more structure?
While I'm clear on why KeyboardInterrupt and SystemExit were moved from
under Exception, it is not at all clear what problem is being solved by
adding a new intermediate grouping.

The PEP needs to address all of the above.  Right now, it contains a
definition rather than justification, research, and analysis.



WindowsError
------------

This should be kept.  Unlike module specific exceptions, this exception
occurs in multiple places and diverse applications.  It is appropriate
to list as a builtin.

"Too O/S specific" is not a reason for eliminating this.  Looking at the
codebase there does not appear to be a good substitute.  Eliminating
this one would break code, decrease clarity, and cause modules to grow
competing variants.

After the change, nothing would be better and many things would be
worse.



NotImplementedError
-------------------
Moving this is fine.  Removing unnecessary nesting is a step forward.
The PEP should list that as a justification.



Bare excepts defaulting to Exception
------------------------------------

After further thought, I'm not as sure about this one and whether it is
workable.  The code fragment above highlights the issue.  In a series of
except clauses, each line only matches what was not caught by a previous
clause.  This is a useful and basic part of the syntax.  It leaves a
bare except to have the role of a final catchall (much like a default in
C's switch-case).  If one line uses "except Exception", then a
subsequence bare except should probably catch KeyboardInterrupt and
SystemExit.  Otherwise, there is a risk of creating optical illusion
errors (code that looks like it should work but is actually broken).
I'm not certain on this one, but the PEP does need to fully explore the
implications and think-out the consequent usability issues. 







> And once that is settled I guess it is either time for pronouncement
> or it just sits there until Python 3.0 actually starts to come upon
> us.

What happened to "don't take this too seriously, I'm just trying to get
the ball rolling"?

This PEP or any Py3.0 PEP needs to sit a good while before
pronouncement.  Because 3.0 is not an active project, the PEP is
unlikely to be a high priority review item by many of Python's best
minds.  It should not be stamped as accepted until they've had a chance
to think it through.  Because 3.0 is still somewhat ethereal, it is not
reasonable to expect them to push aside their other work to look at this
right now.

The PEP needs to be kicked around on the newsgroup (naming and grouping
discussions are easy and everyone will have an opinion).  Also the folks
with PyPy, BitTorrent, Zope, Twisted, IronPython, Jython, and such need
to have a chance to have their say.

Because of Py3.0's low visibility, these PEPs could easily slide through
prematurely.  Were the project imminent, it is likely that this PEP
would have had significantly more discussion.




Try not to get frustrated at these reviews.  Because there was no
research into existing code, working to solve known problems, evaluation
of alternatives, or usability analysis, it is no surprise Sturgeon's Law
would apply.  Since Python has been around so long, it is also no
surprise that what we have now is pretty good and that improvements
won't be trivially easy to come by.



Raymond