On 8/8/05, Raymond Hettinger <[EMAIL PROTECTED]> 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. > > 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? >
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 change:: try: ... except: ... except TerminatingException: ... 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: > > 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. > 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 > worse. > > > > NotImplementedError > ------------------- > 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 . -Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com