[Python-Dev] Exception Reorg PEP revised yet again
bcannon at gmail.com
Tue Aug 9 19:17:42 CEST 2005
On 8/8/05, Raymond Hettinger <python at rcn.com> wrote:
> [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.
> 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
> Are KeyboardInterrupt and SystemExit often caught together on the same
> line and handled in the same way?
The problem with existing code checking for this situation is that the
situation itself is not the same as it will be if bare 'except's
has never really been possible before, but will be if the PEP goes forward.
> If so, isn't "except TerminatingException" less explicit, clear, and
> flexible than "except (KeyboardInterrupt, SystemExit)"? Do we need a
> second way to do it?
But what if we add other exceptions that don't inherit from Exception
that was want to typically propagate up? Having a catch-all for
exceptions that a bare 'except' will skip that is more explicit than
``except BaseException`` seems reasonable to me. As Nick said in
another email, it provides a more obvoius self-documentation point to
catch TerminatingException than ``(KeyboardInterrupt, SystemExit)``,
plus you get some future-proofing on top of it in case we add more
exceptions that are not caught by a bare 'except'.
> Doesn't the new meaning of Exception already offer a better idiom:
> except Exception:
> 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.
> 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.
I unfortunately forgot to add that the exception would be moved under
os, so it would be more of a renaming than a removal.
The reason I pulled it was that Guido said UnixError and MacError
didn't belong, so why should WindowsError stay? Obviously there are
backwards-compatibility issues with removing it, but why should we
have this platform-specific thing in the built-in namespace? Nothing
else is platform-specific in the language until you go into the
stdlib. The language itself is supposed to be platform-agnostic, and
yet here is this exception that is not meant to be used by anyone but
by a specific OS. Seems like a contradiction to me.
> After the change, nothing would be better and many things would be
> Moving this is fine. Removing unnecessary nesting is a step forward.
> The PEP should list that as a justification.
Yay, something uncontraversial! =)
> 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.
This is Guido's thing. You will have to convince him of the change.
I can flesh out the PEP to argue for which ever result he wants, but
that part of the proposal is in there because Guido wanted it. I am
just a PEP lackey in this case. =)
> > 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"?
Nothing, it's called writing the email when I was tired and while I
was trying to fall asleep realizing what I had done. =)
It still needs to go out to c.l.py and will probably sit for a long
while unpronounced. That's the reason I was saying that the
transition plan needs to be fleshed out with 2.x, 2.x+1 version
numbers instead of concrete ones like 2.5 .
More information about the Python-Dev