Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 7/29/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Well, it has been discussed at multiple times in the past and I have > > promised to write this PEP several times, so I finally found enough > > time to write a PEP on reorganizing exceptions for Python 3.0 . > > Thanks for getting this ball rolling! > No problem. Had this bouncing around in my head for a while. I just needed time to finally type it out. > (I wonder what happened to Ping's PEP 344 -- he just dropped out, it > seems.) > Don't know. If he doesn't come back I will pick up the attribute part and roll it into this PEP or a separate PEP. > Below is some feedback. > > > Often people use a bare ``except`` when what they really wanted were > > non-critical exceptions to be caught while more system-specific ones, > > such as MemoryError, to pass through and to halt the interpreter. > > With a hierarchy reorganization, bare ``except`` clauses can be > > changed to only catch exceptions that subclass a non-critical > > exception superclass, allowing more critical exceptions to propagate > > to the top of the execution stack as was most likely intended. > > I appreciate the attempt to make bare except: less dangerous by not > catching certain exceptions, but I worry that these changes might > actually make bare except: *more* likely to be used, which is contrary > to the intention. Maybe we should just get rid of it, and encourage > people to write > > except Exception: > > or > > except Raisable: > > depending on what they want. > Fine by me. I would just make sure that it is suggested people typically catch Exception most of the time and discourage direct catching of Raisable unless they know what they are doing. > > MacError > > UnixError > > Do we really need these? Let's not add things that won't be used. > Is WindowsError used enough to warrant its existence? > > NamespaceException > > > > To provide a common superclass for exceptions dealing with namespace > > issues, this exception is introduced. > > Both UnboundLocalError and UnboundGlobalError (the new name for > > NameError) inherit from this class. > > OTOH there's something to say to unify NameError and AttributeError, > isn't there? Somewhat. You could say that an object is just its own namespace. But I don't see a strong enough correlation to warrant the merging. Or you just saying we should rename AttributeError to NameError? > > EnvironmentError > > > > Originally meant as an exception for when an event outside of the > > interpreter needed to raise an exception, its use has been deemed > > unneeded. > > While both IOError and OSError inherited this class, the distinction > > between OS and I/O is significant enough to not warrant having a > > common subclass that one might base an ``except`` clause on. > > -1000. Depending on whether you use open() or os.open() you'll get > one or the other for pretty much the same thing. > But it doesn't have to stay that way. This is Python 3.0 we are talking about, so we can change how both work. But if you want to keep EnvironmentError that's fine. > Also, I think that socket.error and select.error should inherit from > EnvironmentError (or maybe even from OSError). > Shouldn't the former inherit from IOError? > > RuntimeError > > > Meant to be used when an existing exception does not fit, its > > usefulness is consider meager in Python 2.4 [exceptionsmodule]_. > > Also, with the CriticalException/Exception dichotomy, Exception or > > CriticalException can be raised directly for the same use. > > -0.5. I use it all the time as the "application" exception in apps > (scripts) that are too small to define their own exception hierarchy. > How about GenericException? I just don't think RuntimeError is quite the right name for this. > > StopIteration and GeneratorExit > > > > Inherit from ControlFlowException. > > > > Collecting all control flow-related exceptions under a common > > superclass continues with the theme of maintaining a hierarchy. > > Yes, but how useful it this? I don't expect to ever come across a > situation where I'd want to catch both, so this is more for > organization of the docs than for anything else. > > IMO a good principle for determining the ideal exception hierarchy is > whether there's a use case for catching the common base class. > Well, Robert says there is a use case in CherryPy. > > IOError > > > > No longer subclasses EnvironmentError. > > -1000, see above. > > > Change the Name of Raisable? > > > > It has been argued that Raisable is a bad name to use since it is not > > an actual word [python-dev1]_. > > Then we'll make it a word. Is Java's equivalent, Throwable, any more > a word? In this case I like the parallel with Java. > Fine by me. > > Should Bare ``except`` Clauses be Removed? > > Yes, see above. > OK. -Brett ___ Python-Dev maili
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > New Hierarchy > > = > > > > Raisable (new; rename BaseException?) > > +-- CriticalException (new) > > +-- KeyboardInterrupt > > +-- MemoryError > > +-- SystemExit > > +-- SystemError (subclass SystemExit?) > > I'd recommend not subclassing SystemExit--there are too many programs > out there which expect the argument (e.g. sys.exit(3)) to mean something > specific, but that expectation doesn't apply at all to SystemError. > Don't forget this is Python 3.0; if it makes more sense we can break code. > > +-- Exception (replaces StandardError) > >... > > +-- ControlFlowException (new) > > I'd definitely appreciate ControlFlowException--there are a number of > exceptions in CherryPy which should subclass from that. Um, CherryPy > 3.0, that is. ;) > =) Well, assuming Guido thinks this is enough of a possible use case. > > +-- LookupError (better name?) > > SubscriptError, perhaps? But LookupError could become the "I didn't find > obj X in the container you specified" superclass, in which case > LookupError is perfect. > That's what it's meant for and renaming it GetitemError doesn't exactly clarify it for newbies. =) I doubt something better is going to be found. > > +-- TypeError > > +-- AttributeError (subclassing new) > > "Since most attribute access errors can be attributed to an object not > being the type that one expects, it makes sense for AttributeError to > be considered a type error." > > Very hmmm. I would have thought it would be a LookupError instead, only > because I favor the duck-typing parts of Python. Making AttributeError > subclass from TypeError leans toward stronger typing models a bit too > much, IMO. > This idea has been brought up before on several separate occasions and this subclassing was what was suggested. It seems a decision needs to be made as to whether the lack of an attribute is a failure of using the wrong type of object, just a failure to find something in an object, or a failure to find a name in a namespace. I lean towards the first one, you like the second, and Guido seems to like the third. $20 says Guido's opinion in the end will matter more than ours. =) > > +-- WeakReferenceError (rename for ReferenceError) > > This also has a LookupError feel to it. > Nope, as Fred explains in his own email. > > It has been argued that Raisable is a bad name to use since it is not > > an actual word [python-dev1]_. > > Perhaps, but compare http://www.onelook.com/?w=raisable to > http://www.onelook.com/?w=raiseable. The only sources "raiseable" has > going for it are Dictionary.com (which aggregates lots of questionable > sources), Rhymezone, and LookWAYup. I think "raisable" is the clear > winner. > And Guido seems fine with it, so unless someone can convince Guido otherwise the PEP will go with Raisable. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
OK, I withdraw the suggestion of the subclassing of SystemError by SystemExit. -Brett On 7/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote: > > > +-- SystemExit > > > +-- SystemError (subclass SystemExit?) > > > > I'd recommend not subclassing SystemExit--there are too many programs > > out there which expect the argument (e.g. sys.exit(3)) to mean something > > specific, but that expectation doesn't apply at all to SystemError. > > Agreed. SystemExit is used by sys.exit(); SystemError is something > completely different, used by the interpreter when it finds an > internal invariant is broken. It is one step short of a fatal error -- > the latter is used when we have evidence of random memory scribbling, > the former when the interpreter is still intact. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon wrote: > +-- ControlFlowException (new) While I like the idea of ControlFlowException as the "one obvious way" to break out of multiple nested loops, I'm not convinced StopIteration and GeneratorExit should be inheriting from it. However, I'm even less sure StopIteration and GeneratorExit should be in the Exception portion of the hierarchy at all. This is particularly true of GeneratorExit - I would be very concerned if "except Exception:" were to suppress GeneratorExit. If ControlFlowException was moved up to be a peer of Exception, I'd be much happier with the idea - we would then have four major categories of raisable classes: CriticalException - something is seriously wrong ControlFlowException - an exception is being used to affect control flow in a particular way, and should be intercepted only if you know what that control flow is doing Exception - your every day, run of the mill, exceptions Warning - not really an exception. > +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass > StopIteration?) Definitely not. GeneratorExit was added because the following idiom prevents the use of StopIteration or a subclass to reliably terminate a generator: try: yield itr.next() catch StopIteration: pass > +-- LookupError (better name?) > +-- IndexError > +-- KeyError I don't think there is a particularly strong argument to change the name of LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be gratutitous about it. > +-- TypeError > +-- AttributeError (subclassing new) > +-- NamespaceException (new) > +-- UnboundGlobalError (new name for NameError) > +-- UnboundLocalError (no longer subclasses UnboundGlobalError > which replaces NameError) I'd actually be inclined to make AttributeError a subclass of NameError: +-- NameError +-- AttributeError (subclassing new) +-- UnboundGlobalError (new) +-- UnboundLocalError Current uses of NameError are replaced with UnboundGlobalError. The re-use of NameError reduces the backwards incompatibility, and also concisely summarises the common feature of these three exceptions. > RuntimeError > > Meant to be used when an existing exception does not fit, its > usefulness is consider meager in Python 2.4 [exceptionsmodule]_. > Also, with the CriticalException/Exception dichotomy, Exception or > CriticalException can be raised directly for the same use. Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. Also, gratuitous incompatibility should be avoided, even for Py3k. > Change the Name of Raisable? > > > It has been argued that Raisable is a bad name to use since it is not > an actual word [python-dev1]_. > At issue is choosing a name that clearly explains the class' usage. > "BaseException" might be acceptable although the name does not quite > make it as explicit as Raisable that the class is not meant to be > raised directly. I like Raisable, because it states exactly what the base class indicates: something which can be raised (i.e., used with the "raise" statement). I'm also unclear on why anyone would say it isn't an actual word: http://dictionary.reference.com/search?q=raisable > Should Bare ``except`` Clauses be Removed? > -- I think Explicit Is Better Than Implicit for this one - a bare except which is not the equivalent of "except Raisable" would be quite confusing. So long as the tutorial says that anything broader then "except Exception" is going to be wrong 99.9% of the time, I don't think there will be a problem. > Change the name of Exception? > - Again, there is a strong backwards compatibility argument for keeping the name Exception for the "this is what you should normally catch" category. Mainly, there's a lot of code out there that already uses it this way. Without a compelling argument in favour of a different name, stick with Exception. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon wrote: > On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote: > >>Brett Cannon wrote: >> >>>New Hierarchy >>>= >>> >>>Raisable (new; rename BaseException?) >>>+-- CriticalException (new) >>>+-- KeyboardInterrupt >>>+-- MemoryError >>>+-- SystemExit >>>+-- SystemError (subclass SystemExit?) >> >>I'd recommend not subclassing SystemExit--there are too many programs >>out there which expect the argument (e.g. sys.exit(3)) to mean something >>specific, but that expectation doesn't apply at all to SystemError. >> > > > Don't forget this is Python 3.0; if it makes more sense we can break code. True, but we should still have a decent reason to break stuff. One other thing to keep in mind is that it is easy to handle multiple exception classes with a single except clause - what is hard to fix in user code is inappropriate inheritance between exceptions (cases where you want to 'catch most instances of this class, but not instances of this particular subclass'). >>>+-- Exception (replaces StandardError) >>>... >>>+-- ControlFlowException (new) >> >>I'd definitely appreciate ControlFlowException--there are a number of >>exceptions in CherryPy which should subclass from that. Um, CherryPy >>3.0, that is. ;) >> > > > =) Well, assuming Guido thinks this is enough of a possible use case. Or if he can be persuaded that ControlFlowException should exist as a peer of Exception and CriticalException. . . >>>+-- TypeError >>>+-- AttributeError (subclassing new) >> >>"Since most attribute access errors can be attributed to an object not >>being the type that one expects, it makes sense for AttributeError to >>be considered a type error." >> >>Very hmmm. I would have thought it would be a LookupError instead, only >>because I favor the duck-typing parts of Python. Making AttributeError >>subclass from TypeError leans toward stronger typing models a bit too >>much, IMO. >> > > This idea has been brought up before on several separate occasions and > this subclassing was what was suggested. > > It seems a decision needs to be made as to whether the lack of an > attribute is a failure of using the wrong type of object, just a > failure to find something in an object, or a failure to find a name in > a namespace. I lean towards the first one, you like the second, and > Guido seems to like the third. $20 says Guido's opinion in the end > will matter more than ours. =) I think this is a context thing - whether or not an AttributeError is a TypeError or LookupError depends on the situation. In ducktyping, attributes are used to determine if the object is of the correct type. In this case, an AttributeError indicates a TypeError. However, it isn't that uncommon to use an instance's namespace like a dictionary to avoid typing lots of square brackets and quotes (e.g. many configuration handling modules work this way). In this case, an AttributeError indicates a LookupError. I think it's similar to the common need to convert from KeyError to AttributeError in __getattr__ methods - the extra attributes are looked up in some other container, and the resultant KeyError needs to be converted to an AttributeError by the __getattr__ method. That common use case still doesn't mean KeyError should subclass AttributeError. On the other hand, an AttributeError is _always_ a failure to find a name in a namespace (an instance namespace, rather than locals or globals), so having it inherit from NameError is a reasonable idea. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon wrote: > Well, it has been discussed at multiple times in the past and I have > promised to write this PEP several times, so I finally found enough > time to write a PEP on reorganizing exceptions for Python 3.0 . > > Key points in this PEP is the reworking the hierarchy, requiring > anything raised to inherit from a certain superclass, and to change > bare 'except' clauses to catch a specific superclass. The first and > last points I expect some contention, but the middle point I expect > people are okay with (Guido liked the idea when Paul Prescod brought > it up and the only person who didn't like it, Holger, ended up being > okay with it when the superclass had a reasonable name). I'm not sure what you meant with "the middle", but if this refers to the renaming and reordering of the exception inheritance tree, you can have my -1 on this. I don't have any problem with making all exception inherit from Exception and disallowing bare except clauses. So that's a bit inverse of what you've obviously expected :-) 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. Many applications define their own exception classes which then normally inherit from StandardError. In the application itself, you'd then usually use StandardError for the generic "catch-all except SystemExit" try-excepts. With the new hierarchy, catching Exception (renamed from StandardError) would let e.g. AssertionErrors, SyntaxErrors, etc. that may well have been produced by debugging code or calls to compile() pass through. Since exceptions are also used in the interpreter itself for masking certain situations and, of course, in the gazillion 3rd party extensions out there, your proposed change would also have to be applied to C code - where finding such subtleties is even harder than in plain Python. This is all fine, if we really intend to go for complete breakage and basically require that Python 3 applications need to be written from scratch. I, for one, don't find the existing exception structure all too bad. It has worked for me for many many years without ever having a true need to work around some quirks in the hierarchy. I've had these issues with some 3rd party extensions using the existing Exception class as base-class for their own error classes in cases where a StandardError inheritance would have been much more appropriate, but even there, listing the exceptions in a tuple has so far always helped. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 30 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Barry Warsaw wrote: > On Fri, 2005-07-29 at 16:59, "Martin v. Löwis" wrote: > > >>Perhaps. Somebody would need to research the precise migration >>procedure. I once tried to move the Python CVS to Sunsite >>(or its successors), and gave up after half a year of getting >>nowhere; I'm personally not keen on repeating such an experience. > > > I'm with you. SF is a devil we know. If we don't stick with them (and > it looks like that's not an option if we want to switch to svn soon), > then I say we move it to svn.python.org, where we already have a server > set up and running. If we need more volunteers, well the community has > always stepped up before and I'm sure it will when we come asking again. > > Actually, it's a good idea to /always/ be soliciting for help. People > get burned out and busy and I'd love to have a bullpen of volunteers > that gets constantly refreshed. I guess my point in suggesting a company to do the hosting was to overcome any issues with people getting burned or tired of administration. The PSF does have a reasonable budget, so why not use it to maintain the infrastructure needed for Python development and let a company do the administration of the needed servers and the importing of the CSV and tracker items into their systems ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 30 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
M.-A. Lemburg wrote: > The PSF does have a reasonable budget, so why not use it to > maintain the infrastructure needed for Python development and > let a company do the administration of the needed servers and > the importing of the CSV and tracker items into their > systems ? In principle, this might be a good idea. In practice, it falls short of details: which company, what precisely are their procedures, etc. It's not always the case that giving money to somebody really gives you back the value you expect. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August
PyPy Sprint in Heidelberg 22nd - 29th August 2005 == The next PyPy sprint will take place at the Heidelberg University in Germany from 22nd August to 29th August (both days included). Its main focus is translation of the whole PyPy interpreter to a low level language and reaching 2.4.1 Python compliancy. To learn more about the new PyPy Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint -- One of the main goals of the sprint is going to be a 0.7 release of PyPy. The 0.7 is meant to be the first self-contained PyPy version but still alpha with some C-extension modules missing and not meant for production use. Therefore the topics of the sprint will be: - translation efforts: it's not completely clear now what related task will be left at that time - work on 2.4.1 compliancy: there are some failing compliancy tests on which we plan to work - rewriting c-extension modules/integrating existing rewrites - all kinds of small release issues - possibly some more LLVM efforts Location & Accomodation The sprint will be held in a conference room of the Institute of Physics, University of Heidelberg. We have WLAN connection there and small kitchen to make tea and coffee. `See here`_ how to get there from the Heidelberg main station. There is a huge number of hotels_ in Heidelberg, all of which are unfortunately rather expensive. It should be no problem to reach the sprint venue from anywhere in Heidelberg. As an alternative you could also take a `hotel in Mannheim`_ which you can reach in 15 min from Heidelberg with the train. .. _`See here`: http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php .. _hotels: http://www.cvb-heidelberg.de/index_eng.html .. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm Exact times --- The Pypy sprint is held Monday 22nd August - Monday 29th August 2005. Hours will be from 09:00 until people have had enough. It's a good idea to arrive a day before the sprint starts. Network, Food - The Heidelberg Altstadt can be reached in approximately 10 min from the sprint venue. There you will find all kinds of restaurants and fast food places. You will probably need a wireless network card to access the network although we could set up a WLAN to cable bridge if necessary. Registration etc.pp. Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Heidelberg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt .. _`Heidelberg people`: http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.html .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint -- Samuele Pedroni & the PyPy team ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote: > I'd recommend not subclassing SystemExit--there are too many programs > out there which expect the argument (e.g. sys.exit(3)) to mean > something > specific, but that expectation doesn't apply at all to SystemError. Yes please make note of this for *all* exception (and otherwise) inheritance. You must ensure that any exception B that inherits from A conforms to A's interface! If that isn't the case, it shouldn't inherit. Lots of people seem to forget this, and it's always a pain in the ass. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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: New Hierarchy = Raisable (formerly Exception) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new) +-- GeneratorExit +-- StopIteration +-- SystemExit +-- Exception (formerly StandardError) +-- AssertionError +-- AttributeError +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- EnvironmentError +-- OSError +-- WindowsError (possibly remove this from builtins) +-- IOError +-- EOFError +-- LookupError +-- IndexError +-- KeyError +-- NameError +-- UnboundLocalError +-- RuntimeError +-- NotImplementedError +-- SyntaxError +-- IndentationError +-- TabError +-- ValueError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- FutureWarning +-- PendingDeprecationWarning +-- SemanticsWarning (formerly RuntimeWarning) +-- SyntaxWarning +-- UserWarning Changes from Py 2.4: The big changes: Exception renamed to Raisable StandardError renamed to Exception Rationale for this renaming is that too many people do "except Exception:" when they really mean "except StandardError:". Most applications should cope with this semantics change without much hassle, as the only exceptions that "slip through the net" are KeyboardInterrupt, MemoryError and SystemError. New exception ControlFlowException Make SystemExit a subclass of this Make StopIteration a subclass of this Make GeneratorExit a subclass of this In Python 2.4, the only two exceptions not under StandardError are SystemExit and StopIteration. These are both control flow exceptions - one indicates termination of the application, the other indicates completion of an iterator. Python 2.5 will most likely add GeneratorExit for termination of a generator. Grouping these under a common superclass has a few benefits. - documentation benefit (its obvious why these exceptions are special) - OOWTDI for breaking out of nested loops: raise and catch CFE - module developers can use it to clearly mark their own CFE classes New exception CriticalException Make KeyboardInterrupt a subclass of this Make MemoryError a subclass of this Make SystemError a subclass of this All of these exceptions inherit from StandardError in Python 2.4, but each of them indicates something is seriously wrong. KI indicates Ctrl-C has been pressed, ME indicates the VM has run out of memory, and SE indicates the VM's internals are out of whack. There isn't much a program can or should be doing about these. Certainly, none of them should be getting caught by "except Exception:". The following changes are comparatively minor cleanups: Make EOFError a subclass of IOError Trying to read past the end of a file _is_ an IOError! ReferenceError renamed to WeakReferenceError This recaptures the context that was lost when making this a builtin. RuntimeWarning renamed to SemanticsWarning This better captures the meaning of the warning, and avoids confusion with RuntimeError, which has a very different purpose. A few key differences from Brett's original proposal: I severely culled the Critical Exceptions list. The CE list
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Sat, Jul 30, 2005 at 06:41:51PM +1000, Nick Coghlan wrote:
> Brett Cannon wrote:
> > Don't forget this is Python 3.0; if it makes more sense we can break code.
>
> Or if he can be persuaded that ControlFlowException should exist as a peer of
> Exception and CriticalException. . .
>
> >>>+-- TypeError
> >>>+-- AttributeError (subclassing new)
> >
> > It seems a decision needs to be made as to whether the lack of an
> > attribute is a failure of using the wrong type of object, just a
> > failure to find something in an object, or a failure to find a name in
> > a namespace. I lean towards the first one, you like the second, and
> > Guido seems to like the third. $20 says Guido's opinion in the end
> > will matter more than ours. =)
>
> I think this is a context thing - whether or not an AttributeError is a
> TypeError or LookupError depends on the situation.
>
> In ducktyping, attributes are used to determine if the object is of the
> correct type. In this case, an AttributeError indicates a TypeError.
+1
> However, it isn't that uncommon to use an instance's namespace like a
> dictionary to avoid typing lots of square brackets and quotes (e.g. many
> configuration handling modules work this way). In this case, an
> AttributeError
> indicates a LookupError.
I expect any square-brackets (foo['bar'] or foo[7]) to be a LookupError or
a subclass (KeyError, IndexError). If AttributeError subclassed LookupError
you would have to work around it in common code where you are accessing
an attribute and doing a [] lookup on the same line.
class Foo(object):
bar = {'k' : ['A', 'B', 'C']}
try:
print Foo.barrr['j'][7] # could raise AttributeError, IndexError, KeyError
except (KeyError, IndexError): pass
If the attribute isn't there I made a coding mistake, if the key/index isn't
there my data source doesn't include that item (not a mistake, it just isn't
there).
> I think it's similar to the common need to convert from KeyError to
> AttributeError in __getattr__ methods - the extra attributes are looked up in
> some other container, and the resultant KeyError needs to be converted to an
> AttributeError by the __getattr__ method. That common use case still doesn't
> mean KeyError should subclass AttributeError.
The top level access should dictate which error it raises, even if attributes
are implemented with dictionaries. 'foo.bar' and 'foo.__dict__['bar']' look
different to me, even if the results on success are frequently the same.
Any chance str.index and list.index could raise IndexError instead of
ValueError in 3.0? Even after a few years of using them I still get this
wrong. index() isn't the same lookup as [], but my brain still slips and
expects a function named "index" to raise an "IndexError"
-jackdied
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Sat, Jul 30, 2005, Nick Coghlan wrote: > > 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: Based on skimming (not close examination): +1 We can probably quibble about bits, but I agree that a Grand Restructure should be avoided. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Nick Coghlan wrote: > Here's a fairly minimal proposal, which is closer to the existing 2.4 > structure: > > New Hierarchy > ... I also like this version. -- Brian Beck Adventurer of the First Order ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > +-- ControlFlowException (new) > > While I like the idea of ControlFlowException as the "one obvious way" to > break out of multiple nested loops, I'm not convinced StopIteration and > GeneratorExit should be inheriting from it. > > However, I'm even less sure StopIteration and GeneratorExit should be in the > Exception portion of the hierarchy at all. This is particularly true of > GeneratorExit - I would be very concerned if "except Exception:" were to > suppress GeneratorExit. If ControlFlowException was moved up to be a peer of > Exception, I'd be much happier with the idea - we would then have four major > categories of raisable classes: >CriticalException - something is seriously wrong >ControlFlowException - an exception is being used to affect control flow in > a particular way, and should be intercepted only if you know what that control > flow is doing >Exception - your every day, run of the mill, exceptions >Warning - not really an exception. > I can live with this. I was waivering on putting ControlFlowException under CriticalException, but obviously keeping that dichotomy was more important back when bare 'except' clauses were going to be allowed, but now that it looks like they are being removed I am much more open to putting stuff to inherit directly from Raisable. > > +-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass > > StopIteration?) > > Definitely not. GeneratorExit was added because the following idiom prevents > the use of StopIteration or a subclass to reliably terminate a generator: > >try: > yield itr.next() >catch StopIteration: > pass > Good enough for me. > > +-- LookupError (better name?) > > +-- IndexError > > +-- KeyError > > I don't think there is a particularly strong argument to change the name of > LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be > gratutitous about it. > It looks like the backwards-compatilibity gods are starting to stomp on me; I can sacrifice a renaming to appease them. > > +-- TypeError > > +-- AttributeError (subclassing new) > > +-- NamespaceException (new) > > +-- UnboundGlobalError (new name for NameError) > > +-- UnboundLocalError (no longer subclasses UnboundGlobalError > > which replaces NameError) > > I'd actually be inclined to make AttributeError a subclass of NameError: > >+-- NameError >+-- AttributeError (subclassing new) >+-- UnboundGlobalError (new) >+-- UnboundLocalError > > Current uses of NameError are replaced with UnboundGlobalError. The re-use of > NameError reduces the backwards incompatibility, and also concisely summarises > the common feature of these three exceptions. > Hmm. Well, I think it was either Tim or Barry (or both) who once suggested AttributeError inherit from TypeError, but they have not spoken up nor has anyone else so far supporting the idea. But then again people have argued for LookupError instead. I am going to have to think about this one before I attempt to reply on this topic. > > RuntimeError > > > > Meant to be used when an existing exception does not fit, its > > usefulness is consider meager in Python 2.4 [exceptionsmodule]_. > > Also, with the CriticalException/Exception dichotomy, Exception or > > CriticalException can be raised directly for the same use. > > Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. > Also, gratuitous incompatibility should be avoided, even for Py3k. > OK, but is the name so great? Yes, it is a runtime error, but it just doesn't hit the point of it being a dirty little exception to use when you don't want to create a new one. How about GenericException or SimpleException? Or are the backwards-compatibility gods going to smack me again for this suggestion and spout something off containing the words "not" and "Perl 6"? =) > > Change the Name of Raisable? > > > > > > It has been argued that Raisable is a bad name to use since it is not > > an actual word [python-dev1]_. > > At issue is choosing a name that clearly explains the class' usage. > > "BaseException" might be acceptable although the name does not quite > > make it as explicit as Raisable that the class is not meant to be > > raised directly. > > I like Raisable, because it states exactly what the base class indicates: > something which can be raised (i.e., used with the "raise" statement). I'm > also unclear on why anyone would say it isn't an actual word: > > http://dictionary.reference.com/search?q=raisable > I think the point was it was not in someone's spell checker. But I consider this point settled since Guido said he was fine with creating a new word. > > Should Bare ``except`` Clauses be Removed? > > -- > I think Explicit Is
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
At 11:43 PM 7/30/2005 +1000, Nick Coghlan wrote: >Here's a fairly minimal proposal, which is closer to the existing 2.4 >structure: > >New Hierarchy >= > >Raisable (formerly Exception) >+-- CriticalException (new) > +-- KeyboardInterrupt > +-- MemoryError > +-- SystemError >+-- ControlFlowException (new) > +-- GeneratorExit > +-- StopIteration > +-- SystemExit >+-- Exception (formerly StandardError) > +-- AssertionError > +-- AttributeError > +-- ImportError > +-- TypeError > +-- WeakReferenceError (formerly ReferenceError) I like this a lot, and a good bit of it could actually be done in 2.5, apart from the Exception/StandardError move, assuming also that the renamed errors were also available under their old names. We could probably go so far as to add Raisable to the hierarchy, but I don't think we could actually get quite to your proposed structure without breaking any programs. On the other hand, if we introduce CriticalException and ControlFlowException in 2.5 (inheriting from Exception), and create a new Error base for StandardError, then promote subclassing and catching it instead of Exception, then there will be less to do in 3.0. So, my thoughts for the 2.x series are: Exception CriticalException ControlFlowException Error StandardError with the children of these being as you've proposed. Now, "except Error:" would be the replacement for a bare except in most cases, and we would recommend subclassing one of the three Exception subclasses instead of Exception itself, maybe even introduce a PendingDeprecationWarning for direct Exception subclasses outside the exceptions module, with a DeprecationWarning in 2.6 and beyond. Note that subclassing Error instead of Exception won't hurt any programs that already catch Exception, and if they have to deal with libraries that haven't made the move, they can always use this pattern: except (CriticalException,ControlFlowException): raise except: # whatever ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > Well, it has been discussed at multiple times in the past and I have > > promised to write this PEP several times, so I finally found enough > > time to write a PEP on reorganizing exceptions for Python 3.0 . > > > > Key points in this PEP is the reworking the hierarchy, requiring > > anything raised to inherit from a certain superclass, and to change > > bare 'except' clauses to catch a specific superclass. The first and > > last points I expect some contention, but the middle point I expect > > people are okay with (Guido liked the idea when Paul Prescod brought > > it up and the only person who didn't like it, Holger, ended up being > > okay with it when the superclass had a reasonable name). > > I'm not sure what you meant with "the middle", Actually, it was referencing the bare 'except' clauses and changing their semantics. > but if this > refers to the renaming and reordering of the exception > inheritance tree, you can have my -1 on this. > > I don't have any problem with making all exception inherit > from Exception and disallowing bare except clauses. > Do you mean all inherit from Exception in order for it be allowed to be passed to 'raise'? > So that's a bit inverse of what you've obviously expected :-) > If this becomes a theme, yes. But specifically coming from you, MAL, no, not really. =) > 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. > My view of Python 3.0 was that backwards-compatibility would not be a gimme in anyway. I personally am willing to break stuff in the name of clarity, which is the point of this whole endeavour. While I am willing to back off on some the proposed changes, I do think the basic spirit of it is correct. > 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. > Right, so the renaming is not a huge problem. > 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. > > Many applications define their own exception classes > which then normally inherit from StandardError. In the > application itself, you'd then usually use StandardError > for the generic "catch-all except SystemExit" try-excepts. > With the new hierarchy, catching Exception (renamed from > StandardError) would let e.g. AssertionErrors, SyntaxErrors, > etc. that may well have been produced by debugging code > or calls to compile() pass through. > Right, but if we introduce aliases in Python 2.9 or sooner the transition will be much easier and they will know to rename things. And obviously warnings can be used for people to know that the hierarchy will change. I bet we will put in a PendingDeprecationWarning or SemanticsWarning saying that the inheritance will be different in Python 3.0 . Yes, this will incur more work than had we left it alone, but the whole point of Python 3.0 is to remove quirks. > Since exceptions are also used in the interpreter itself > for masking certain situations and, of course, in the > gazillion 3rd party extensions out there, your proposed > change would also have to be applied to C code - where > finding such subtleties is even harder than in plain > Python. > If we fiddle with the exception code raising a Warning will not be too bad for this. Plus you can grep for PyExc_TypeError easily enough to see where you are using classes that have a new inheritance tree. > This is all fine, if we really intend to go for complete > breakage and basically require that Python 3 applications > need to be written from scratch. > I for one don't expect Python 2.x code to run automatically without some fiddling. I think saying from scratch is a little strong. > I, for one, don't find the existing exception structure > all too bad. It has worked for me for many many years > without ever having a true need to work around some > quirks in the hierarchy. I've had these issues with some > 3rd party extensions using the existing Exception class > as base-class for their own error classes in cases where > a StandardError inheritance would have been much more > appropriate, but even there, listing the exceptio
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, James Y Knight <[EMAIL PROTECTED]> wrote: > On Jul 29, 2005, at 11:07 PM, Robert Brewer wrote: > > > I'd recommend not subclassing SystemExit--there are too many programs > > out there which expect the argument (e.g. sys.exit(3)) to mean > > something > > specific, but that expectation doesn't apply at all to SystemError. > > Yes please make note of this for *all* exception (and otherwise) > inheritance. You must ensure that any exception B that inherits from > A conforms to A's interface! If that isn't the case, it shouldn't > inherit. Lots of people seem to forget this, and it's always a pain > in the ass. > The reason for requiring inheriting from Raisable is so that the basic interface will be guaranteed for any caught exception. And I don't think that any of the built-ins have any specific attributes sans maybe OSError, but that is a leaf in the inheritance tree so that is not a problem. Don't worry, the interfaces won't change in the middle of a branch. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon wrote: > 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? =) It's like editing creative writing - I find it far, far easier to take something good and tweak it to make it better, than to come up with something good in the first place ;) >>+-- 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. Exactly my thought. I had it under "NameError" for a while, but had difficulty coming up with a case where lumping it in with the lexical scoping errors was actually beneficial. Eventually, the fact that it is easy to add another exception to an except clause, but hard to remove a child you don't want that inherits from a parent you do want persauded me to leave this one alone. >> +-- 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. True. And the interface looks the same as the normal OSError interface, so it should be possible to replace all uses with a basic OSError. >> +-- NameError >> +-- UnboundLocalError > > > What about UnboundGlobalError? I realised this was a misnomer. A failed name lookup actually means: - the name was not in locals - the name was not in any lexically containing scope - the name was not in the module globals - the name was not in builtins The program doesn't know which of those namespaces was *meant* to contain the name - it only knows that none of them actually contained it. This criticism also applies to the current wording of the NameError text used in this situation (which implies the name should have been in the module globals). Now, a case could possibly be made for separate errors for cases like the following: def f(): global x print x # UnboundGlobalError (currently NameError, with usual text) def f(): def g(): print x g() # UnboundFreeVariableError (currently NameError, with specific text) x = 1 Like UnboundLocalError, in both of these cases, the name is potentially known to the compiler - it simply hasn't been bound to anything yet. >> +-- RuntimeError > I still don't like the name. I'm not that fond of it either - but as the builtin exception most likely to be used (abused?) by user code, I expect changing its name would be more pain than it's worth. >> +-- 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. This particular inheritance is copied from Python 2.4 :) I find the main trick with making RuntimeError more palatable is to avoid thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'. That's not what this error is about - a Python VM error is a SystemError. Instead, a RuntimeError is a generic application error - something which happened during happened at program runtime. Renaming RuntimeWarning to SemanticsWarning should help with that distinction. >>+-- Warning >> +-- DeprecationWarning >> +-- FutureWarning >> +-- PendingDeprecationWarning > > > Don't like the idea of having DeprecationWarning inherit from > PendingDeprecationWarning? Not really. Mainly because I'm not sure which way the inheritance should go - I could understand someone wanting to suppress PendingDeprecationWarnings without suppressing DeprecationWarnings. On the other hand, there's your argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a shorter timeframe'. Again, I fell back on the concept that Python's except clause makes it easy to ask for both if you want both, but makes it relatively difficult to undo exception inheritance if it isn't what you want. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Phillip J. Eby wrote: > I like this a lot, and a good bit of it could actually be done in 2.5, > apart from the Exception/StandardError move, assuming also that the > renamed errors were also available under their old names. We could > probably go so far as to add Raisable to the hierarchy, but I don't > think we could actually get quite to your proposed structure without > breaking any programs. On the other hand, if we introduce > CriticalException and ControlFlowException in 2.5 (inheriting from > Exception), and create a new Error base for StandardError, then promote > subclassing and catching it instead of Exception, then there will be > less to do in 3.0. So, my thoughts for the 2.x series are: > > >Exception > CriticalException > ControlFlowException > Error > StandardError If we leave Exception at the top of the hierarchy for Py3k, and use Error to replace StandardError, the hierarchy could look like this: Exception +-- ControlFlowException (new) +-- GeneratorExit +-- KeyboardInterrupt +-- StopIteration +-- SystemExit +-- CriticalError (new) +-- MemoryError +-- SystemError +-- Error (formerly StandardError) +-- AssertionError +-- AttributeError +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError) I wouldn't mind using Exception/Error instead of Raisable/Exception - and it seriously reduces the pain of making this transition. Indeed, most of it becomes doable within the 2.x series - the only tricky parts are semantic changes involved with moving the KeyboardInterrupt, MemoryError and SystemError out from under StandardError, and moving EOFError under IOError. So the question is whether or not the Raisable/Exception combination is liked enough that we want to dance through the requisite hoops to get there. Notice that I've classified KeyboardInterrupt as user-initiated control flow and put it under ControlFlowException above. This means that everything under CriticalError and Error actually ends with the word 'Error'. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Brett Cannon <[EMAIL PROTECTED]> wrote: > > > > +-- Warning > > > +-- DeprecationWarning > > > +-- FutureWarning > > > +-- PendingDeprecationWarning > > > > Don't like the idea of having DeprecationWarning inherit from > > PendingDeprecationWarning? > > Not all DeprecationWarnings are Pending, but all > PendingDeprecationWarnings are DeprecationWarnings. > See, I don't agree with that logic. DeprecationWarning means something has been deprecated, while PendingDeprecationWarning means something will be deprecated in the future. I am say that the for DeprecationWarning, the future is now and thus is a PendingDeprecationWarning as well. It also just makes sense from the standpoint of catching warnings. If you care about catching PendingDeprecationWarning you are going to care about catching a DeprecationWarning since if you are worrying about the less severe version you are definitely going to care about the most severe case. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > 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? =) > > It's like editing creative writing - I find it far, far easier to take > something good and tweak it to make it better, than to come up with something > good in the first place ;) > You stand on the shoulder of a giant (and I am only partially kidding; people who have met me will get the joke)! > >>+-- 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. > > Exactly my thought. I had it under "NameError" for a while, but had difficulty > coming up with a case where lumping it in with the lexical scoping errors was > actually beneficial. > > Eventually, the fact that it is easy to add another exception to an except > clause, but hard to remove a child you don't want that inherits from a parent > you do want persauded me to leave this one alone. > I think this one will require BDFL pronouncement to be moved since this already looks like a contested idea. And I don't think Guido is going to care enough to want to see it moved. > >> +-- 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. > > True. And the interface looks the same as the normal OSError interface, so it > should be possible to replace all uses with a basic OSError. > Glad you agree. =) > >> +-- NameError > >> +-- UnboundLocalError > > > > > > What about UnboundGlobalError? > > I realised this was a misnomer. A failed name lookup actually means: >- the name was not in locals >- the name was not in any lexically containing scope >- the name was not in the module globals >- the name was not in builtins > > The program doesn't know which of those namespaces was *meant* to contain the > name - it only knows that none of them actually contained it. This criticism > also applies to the current wording of the NameError text used in this > situation (which implies the name should have been in the module globals). > > Now, a case could possibly be made for separate errors for cases like the > following: > >def f(): > global x > print x # UnboundGlobalError (currently NameError, with usual text) > >def f(): > def g(): >print x > g() # UnboundFreeVariableError (currently NameError, with specific text) > x = 1 > > Like UnboundLocalError, in both of these cases, the name is potentially known > to the compiler - it simply hasn't been bound to anything yet. > That was what I was thinking as the use case for UnboundGlobalError. Also, if you read the docs on NameError, it explicitly states that it is for global names that are not found. I am willing to toss in an exception for the failure to find a free variable (although I would call it UnboundFreeError) to flesh this namespace hierarchy out. Then again you could argue you should inherit from each other since a missing local is kind of lack missing the global namespace as well, but that kind of purity just doesn't work for me in this case. [rest of my response to this email is forthcoming] -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: [SNIP] > >> +-- RuntimeError > > I still don't like the name. > > I'm not that fond of it either - but as the builtin exception most likely to > be used (abused?) by user code, I expect changing its name would be more pain > than it's worth. > Maybe, but I am still going to nudge for a change. It might get shot down in the end, but at least I can say I tried. > >> +-- 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. > > This particular inheritance is copied from Python 2.4 :) > Ah, oops. =) Well, I still don't think they should inherit like that and instead be decoupled. > I find the main trick with making RuntimeError more palatable is to avoid > thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'. > That's not what this error is about - a Python VM error is a SystemError. > Instead, a RuntimeError is a generic application error - something which > happened during happened at program runtime. > Right, you shouldn't think that, but isn't that what you thought initially? That is why I want to rename RuntimeError. > Renaming RuntimeWarning to SemanticsWarning should help with that distinction. > Well, not once the name is changed since people won't know about the former name connection. =) > >>+-- Warning > >> +-- DeprecationWarning > >> +-- FutureWarning > >> +-- PendingDeprecationWarning > > > > > > Don't like the idea of having DeprecationWarning inherit from > > PendingDeprecationWarning? > > Not really. Mainly because I'm not sure which way the inheritance should go - > I could understand someone wanting to suppress PendingDeprecationWarnings > without suppressing DeprecationWarnings. On the other hand, there's your > argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a > shorter timeframe'. > > Again, I fell back on the concept that Python's except clause makes it easy to > ask for both if you want both, but makes it relatively difficult to undo > exception inheritance if it isn't what you want. > True, but the hierarchy should still properly reflect increasing severity in my opinion. I am going to push for this; we will see if I get pushed back enough to not do it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > I like this a lot, and a good bit of it could actually be done in 2.5, > > apart from the Exception/StandardError move, assuming also that the > > renamed errors were also available under their old names. We could > > probably go so far as to add Raisable to the hierarchy, but I don't > > think we could actually get quite to your proposed structure without > > breaking any programs. On the other hand, if we introduce > > CriticalException and ControlFlowException in 2.5 (inheriting from > > Exception), and create a new Error base for StandardError, then promote > > subclassing and catching it instead of Exception, then there will be > > less to do in 3.0. So, my thoughts for the 2.x series are: > > > > > >Exception > > CriticalException > > ControlFlowException > > Error > > StandardError > > If we leave Exception at the top of the hierarchy for Py3k, and use Error to > replace StandardError, the hierarchy could look like this: > > Exception > +-- ControlFlowException (new) >+-- GeneratorExit >+-- KeyboardInterrupt >+-- StopIteration >+-- SystemExit > +-- CriticalError (new) >+-- MemoryError >+-- SystemError > +-- Error (formerly StandardError) >+-- AssertionError >+-- AttributeError >+-- ImportError >+-- TypeError >+-- WeakReferenceError (formerly ReferenceError) > > I wouldn't mind using Exception/Error instead of Raisable/Exception - and it > seriously reduces the pain of making this transition. Indeed, most of it > becomes doable within the 2.x series - the only tricky parts are semantic > changes involved with moving the KeyboardInterrupt, MemoryError and > SystemError out from under StandardError, and moving EOFError under IOError. > I can live with this, but that will require Guido's stamp of approval. > So the question is whether or not the Raisable/Exception combination is liked > enough that we want to dance through the requisite hoops to get there. > > Notice that I've classified KeyboardInterrupt as user-initiated control flow > and put it under ControlFlowException above. This means that everything under > CriticalError and Error actually ends with the word 'Error'. > I don't know if I like this change in inheritance. While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I prefer the latter explanation. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 7/30/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > Brett Cannon <[EMAIL PROTECTED]> wrote: > > > > > > +-- Warning > > > > +-- DeprecationWarning > > > > +-- FutureWarning > > > > +-- PendingDeprecationWarning > > > > > > Don't like the idea of having DeprecationWarning inherit from > > > PendingDeprecationWarning? > > > > Not all DeprecationWarnings are Pending, but all > > PendingDeprecationWarnings are DeprecationWarnings. > > > > See, I don't agree with that logic. DeprecationWarning means > something has been deprecated, while PendingDeprecationWarning means > something will be deprecated in the future. I am say that the for > DeprecationWarning, the future is now and thus is a > PendingDeprecationWarning as well. > > It also just makes sense from the standpoint of catching warnings. If > you care about catching PendingDeprecationWarning you are going to > care about catching a DeprecationWarning since if you are worrying > about the less severe version you are definitely going to care about > the most severe case. Well, I would also disagree with your logic. I would mask the pending deprecations because they are still pending, but when they are actually deprecated, I would like to know about it, hence wouldn't mask it. By having DeprecationWarning inherit from PendingDeprecationWarning as you suggest, I would not have the ability to do so, and neither would anyone else. Because there are two different ways of seeing it, and neither of us is likely to convince the other, perhaps it is better for the fate of of this conversation that they aren't inheriting from one or the other, and people can be explicit about what kinds of deprecations they want to mask. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Sat, Jul 30, 2005, Brett Cannon wrote: > > My view of Python 3.0 was that backwards-compatibility would not be a > gimme in anyway. I personally am willing to break stuff in the name > of clarity, which is the point of this whole endeavour. While I am > willing to back off on some the proposed changes, I do think the basic > spirit of it is correct. My take is that for Python 3.0, backwards compatibility is no longer a critical priority -- but any breakage still needs to be argued for and balanced. We want to avoid unnecessary breakage. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
On Saturday 30 July 2005 22:20, Brett Cannon wrote: > True, but the hierarchy should still properly reflect increasing > severity in my opinion. I am going to push for this; we will see if I > get pushed back enough to not do it. I have no idea what you mean by "properly reflect increasing severity". Should the more severe or less severe case be derived from the other? I doubt there is a single answer that we can readily agree on. If DeprecationWarning and PendingDeprecationWarning need a class-hierarchy relationship (and I think they do; it *is* reasonable for someone to deal with them generically if they can reasonably want to deal with either), then it seems they need a common base: +--AnyDeprecationWarning +--DeprecationWarning +--PendingDeprecationWarning -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
