On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> 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 generic warning but for dubious runtime behavior being changed. If it is truly meant to be generic (I think of UserWarning for that), then fine, I can let go of the name change. But it just took a friend of mine with no exposure to the warning system 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 RuntimeWarning and 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 is meant for) sucks as a name for a generic exception. I didn't know that was its use until I read the docs and Guido pointed out during the discussion of this thread. I am willing to compromise with a new exception that inherits RuntimeError named SimpleError (or the inheritance can be flipped). -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