Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP,take 2: Exception Reorganization for Python 3.0
Brett Cannonbcannon at gmail.com
Fri Aug 5 23:05:00 CEST 2005
On 8/5/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:> Also strong -1 on renaming RuntimeWarning to SemanticsWarning.>> Besides being another unnecessary change (trying to solve a non-existent> problem), this isn't an improvement. The phrase RuntimeWarning is> sufficiently generic to allow it to be used for a number of purposes.> In costrast, SemanticsWarning is less flexible. Worse, it is not at all> clear what a Semantics Warning would mean -- it suggests something much> more ominous and complicated that it should.>But the docs don't say that RuntimeWarning is meant as a genericwarning but for dubious runtime behavior being changed. If it istruly meant to be generic (I think of UserWarning for that), thenfine, I can let go of the name change.But it just took a friend of mine with no exposure to the warningsystem to understand what it meant.> Another risk from gratuitous changes is the risk of unexpectedly> introducing new problems. In this case, I find myself remembering the> name as SemanticWarning instead of SemanticsWarning. These kind of> changes suck -- they fail to take advantage of 15 years of field testing> and risk introducing hard-to-change usability problems.>OK, I can see the typos from that, but I still think RuntimeWarningand Error, for use as a generic exception, suck as names.> Likewise, am a strong -1 on renaming RuntimeError to UserError. The> latter name has some virtues but it is also misread as the User doing> something wrong -- that is definitely not the intended meaning. While> RuntimeError is a less than perfect name, it should not be changed> unless we have both 1) demonstrated that real world problems have> occurred with the current name and 2) that we have a clearly superior> alternative name (a test which UserError fails). The only virtue to the> name, UserError, is its symmetry with UserWarning.>SimpleError?> -0 on renaming ReferenceError to WeakReferenceError. The new name does> better suggest the cause. OTOH, the context of the traceback would also> make that perfectly clear. I'm not aware of a single user having had a> problem with the current name. In general, we've avoided long names in> favor of the short and pithy -- the theory was that the only a mnemonic> is needed. Before adopting this one, there should be some discussion of> 1) whether the current name is really that unclear, 2) whether shorter> alternatives would serve (i.e. WeakrefError), and 3) whether the name> suffers from capitalization ambiguity (WeakreferenceError vs> WeakReferenceError).>Will I didn't know what the exception was for until I read the docs. Granted this was just from looking at ``import exceptions;dir(exceptions)``, but why shouldn't the names be that obvious?And I don't see a capitalization ambiguity; if it was WeakrefError,sure. But not when the entire phrase is used.> Summary: Most of the proposed name changes are unnecessary, the new> names are not necessarily better, and there is a high risk of> introducing new usability problems.>I still think RuntimeError (and RuntimeWarning if that is what it ismeant for) sucks as a name for a generic exception. I didn't knowthat was its use until I read the docs and Guido pointed out duringthe discussion of this thread.I am willing to compromise with a new exception that inheritsRuntimeError named SimpleError (or the inheritance can be flipped).-Brett
More information about the Python-Devmailing list
[8]ページ先頭