[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Brett Cannon]

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.
> 

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