[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
bcannon 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 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.
> -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
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).
More information about the Python-Dev