Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP,take 2: Exception Reorganization for Python 3.0
Brett Cannonbcannon at gmail.com
Thu Aug 4 00:47:54 CEST 2005
On 8/3/05, James Y Knight <foom at fuhm.net> wrote:> On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:> > [...brain hums...]> >> > OK, I'm changing my mind again about the names again.> >> > Exception as the root and StandardError can stay; the only new> > proposal would then be to make bare 'except:' call StandardError.>> I don't see how that can work. Any solution that is expected to> result in a usable hierarchy this century must preserve "Exception"> as the object that user exceptions should derive from (and therefore> that users should generally catch, as well). There is way too much> momentum behind that to change it.>Oh, I bet Guido can make them change. =)Look at it this way; going with the Raisable/Exception change andhaving bare 'except's catch Exception will still lead to a semanticchange since CriticalError and ControlFlowException will not becaught. Breakage is going to happen, so why not just do a morethorough change that leads to more breakage?Obviously you are saying to minimize it while Guido is saying to gofor a more thorough change. So how much more code is going to crapout with this change? Everything under our control will be fine sincewe can change it. User-defined exceptions might need to be changed ifthey inherit directly from Exception instead of StandardError, whichis probably the common case, but changing a superclass is not hard. That kind of breakage is not bad since you can easily systematicallychange superclasses of exceptions from Exception to StandardErrorwithout much effort thanks to regexes.I honestly think the requirement of inheriting from a specificsuperclass will lead to more breakage since you can't grep forexceptions that don't at least inherit from *some* exceptionuniversally.-Brett
More information about the Python-Devmailing list
[8]ページ先頭