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.
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. 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 WeakReferenceError). 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. Raymond _______________________________________________ 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
