On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg wrote: > > The reason for my -1 on the renaming and reordering is > > that it would completely break compatibility of Python 2.x > > applications with Python 3. Furthermore, there would be next to > > no chance of writing new applications that run in Python 3 > > and 2, so you have breakage in both directions. > > > > Whether this is desired or not is a different discussion, > > I just want to point out some important things to consider: > > > > When moving from Python 2.x to 3.0, renaming could be solved > > with the help of some scripts, grep et al. However, there > > would have to be a good reason for each of these renamings, > > otherwise this only introduces additional porting overhead. > > Aliases might be a way to provide soft introduction. > > > > Something that scripts will not be able to help with are > > changes in the inheritance tree, e.g. if an application > > catches a ValueError, the programmer might also expect > > UnicodeErrors to get caught, if the application catches > > a TypeError, this may not be aware that the TypeError could > > actually be an AttributeError. > > I think the problems with this can be minimised by avoiding making changes we > don't need to. I think only a few changes are needed to get a significantly > cleaner structure. > > Here's a fairly minimal proposal, which is closer to the existing 2.4 > structure: >
Nick, are you going go start subbing in for Tim when he is busy and take my work that I spent hours on, come up with an alternative that took 10 minutes, and have everyone end up loving your newfangled idea 10x more than my original? =) > New Hierarchy > ============= > > Raisable (formerly Exception) > +-- CriticalException (new) > +-- KeyboardInterrupt > +-- MemoryError > +-- SystemError > +-- ControlFlowException (new) As I have said I am fine with moving ControlFlowException out to here, but it depends if others agree. > +-- GeneratorExit > +-- StopIteration > +-- SystemExit Good point with SystemExit! I am definitely +1 on changing that inheritance. > +-- Exception (formerly StandardError) > +-- AssertionError > +-- AttributeError I am still up for moving AttributeError, but with the amount of arguing going on between where it should go I am not going to be shocked if we go with the status quo. > +-- ImportError > +-- TypeError > +-- WeakReferenceError (formerly ReferenceError) > +-- ArithmeticError > +-- FloatingPointError > +-- DivideByZeroError > +-- OverflowError > +-- EnvironmentError > +-- OSError > +-- WindowsError (possibly remove this from builtins) If we are going to lack exceptions for other OSs, I say remove it. No reason Windows should get special treatment with a built-in exception. > +-- IOError > +-- EOFError > +-- LookupError > +-- IndexError > +-- KeyError > +-- NameError > +-- UnboundLocalError What about UnboundGlobalError? > +-- RuntimeError I still don't like the name. > +-- NotImplementedError Interesting idea, but I don't view them as the same. Everyone uses RuntimeError as a Poor Man's Exception, not as an actual runtime error. > +-- SyntaxError > +-- IndentationError > +-- TabError > +-- ValueError > +-- UnicodeError > +-- UnicodeDecodeError > +-- UnicodeEncodeError > +-- UnicodeTranslateError > +-- Warning > +-- DeprecationWarning > +-- FutureWarning > +-- PendingDeprecationWarning Don't like the idea of having DeprecationWarning inherit from PendingDeprecationWarning? -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
