Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
James Y Knight <[EMAIL PROTECTED]> wrote: > > OK, I'm changing my mind again about the names again. > > > > Exception as the root and StandardError can stay; the only new > > proposal would then be to make bare 'except:' call StandardError. > > I don't see how that can work. Any solution that is expected to > result in a usable hierarchy this century must preserve "Exception" > as the object that user exceptions should derive from (and therefore > that users should generally catch, as well). There is way too much > momentum behind that to change it. Well, in the last few years I always derived my own exceptions from StandardError and used `except StandardError` instead of `except Exception`. And I'd love to get rid of the except KeyboardInterrupt: raise clause I currently have to write before any `except StandardError`. -- Christian Tanzerhttp://www.c-tanzer.at/ ___ 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
[Python-Dev] [ python-Patches-790710 ] breakpoint command lists in pdb
Hello, This patch is about to celebrate its second birthday :-) https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470 It seems from the comments that the feature is nice but the implementation was not OK. I redid the implem according to the comments. What should I do to get it reviewed further ? (perhaps just this : posting to python-dev :-) Best, -- Grégoire ___ 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
Re: [Python-Dev] [ python-Patches-790710 ] breakpoint command lists inpdb
"Grégoire Dooms" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >This patch is about to celebrate its second birthday :-) >What should I do to get it reviewed further ? The guaranteed-by-a-couple-of-developers way is to review 5 other patches, post a summary here, and name this as the one you want reviewed in exchange. TJR ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
One more thing. Is renaming NameError to NamespaceError really worth it? I'd say that NameError is just as clear. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
[ Guido] > One more thing. Is renaming NameError to NamespaceError really worth > it? I'd say that NameError is just as clear. +1 on NameError -- it's clear, easy to type, isn't a gratuitous change, and doesn't make you think twice about NamespaceError vs NameSpaceError. 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
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
[Python-Dev] PEP 348: Exception Reorganization for Python 3.0
The PEP moves StopIteration out from under Exception so that it cannot be caught by a bare except or an explicit "except Exception". IMO, this is a mistake. In either form, a programmer is stating that they want to catch and handle just about anything. There is a reasonable argument that SystemExit special and should float to the top, but that is not the case with StopIteration. When a user creates their own exception for exiting multiple levels of loops or frames, should they inherit from ControlFlowException on the theory that it no different in intent from StopIteration or should they inherit from UserError on the theory that it is a custom exception? Do you really want routine control-flow exceptions to bypass "except Exception". I suspect that will lead to coding errors that are very difficult to spot (it sure looks like it should catch a StopIteration). Be careful with these proposals. While well intentioned, they have ramifications that aren't instantly apparent. Each one needs some deep thought, user discussion, usability testing, and a darned good reason for changing what we already have in the field. 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The PEP moves StopIteration out from under Exception so that it cannot > be caught by a bare except or an explicit "except Exception". > > IMO, this is a mistake. In either form, a programmer is stating that > they want to catch and handle just about anything. There is a > reasonable argument that SystemExit special and should float to the top, > but that is not the case with StopIteration. > > When a user creates their own exception for exiting multiple levels of > loops or frames, should they inherit from ControlFlowException on the > theory that it no different in intent from StopIteration or should they > inherit from UserError on the theory that it is a custom exception? I say ControlFlowException. UserError is meant for quick-and-dirty exception usage and not as a base for user error exceptions. If the name is confusing it can be changed to SimpleError. > Do > you really want routine control-flow exceptions to bypass "except > Exception". Yes. > I suspect that will lead to coding errors that are very > difficult to spot (it sure looks like it should catch a StopIteration). > I honestly don't think it will. People who are going to care about catching StopIteration are writing custom iterators, not something a newbie will porobably be doing and thus should know to be specific about what exceptions they are catching when they have a specific thing in mind. > Be careful with these proposals. While well intentioned, they have > ramifications that aren't instantly apparent. Each one needs some deep > thought, user discussion, usability testing, and a darned good reason > for changing what we already have in the field. > Right, which is why this is all in a PEP, so the discussion can happen and the kinks can be worked out. As for the testing, that can happen with __future__ statements, people trying out a patch, or maybe even some testing branch of Python for possible 3000 features. -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote (in the PEP): > > KeyboardInterrupt inheriting from ControlFlowException > > > > KeyboardInterrupt has been a contentious point within this hierarchy. Some > > view the exception as more control flow being caused by the user. But with > > its asynchronous cause thanks to the user being able to trigger the > > exception at any point in code it has a more proper place inheriting from > > CriticalException. It also keeps the name of the exception from being > > "CriticalError". > > I think this argues against your own hierarchy, since you _did_ call the > parent exception CriticalError. By your argument above, that suggests > KeyboardInterrupt doesn't belong there ;) > =) Drawback of having names swapped in and out so many times. > In practice, whether KeyboardInterrupt inherits from ControlFlowException or > CriticalError shouldn't be a big deal - the important thing is to get it out > from under Exception and StandardError. > In general, probably. > At which point, the naming issue is enough to incline me towards christening > it a ControlFlowException. It gets all the 'oddly named' exceptions into one > place. > Good point. I think I would like to see Guido's preference for this since it feels like it should be under CriticalError. > Additionally, consider that a hypothetical ThreadExit exception (used to > terminate a thread semi-gracefully) would also clearly belong under > ControlFlowException. That is, just because something is asynchronous with > respect to the currently executing code doesn't necessarily make it an error > (yes, I know I argued the opposite point the other day. . .). > Another good point. I am leaning towards moving it now, but I still would like to hear Guido's preference, if he has one. -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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
At 02:46 PM 8/5/2005 -0400, Raymond Hettinger wrote: >The PEP moves StopIteration out from under Exception so that it cannot >be caught by a bare except or an explicit "except Exception". > >IMO, this is a mistake. In either form, a programmer is stating that >they want to catch and handle just about anything. There is a >reasonable argument that SystemExit special and should float to the top, >but that is not the case with StopIteration. While I agree with most of your -1's on gratuitous changes, this particular problem isn't gratuitous. A StopIteration that reaches a regular exception handler is a programming error; allowing StopIteration and other control-flow exceptions to be caught other than explicitly *masks* programming errors. Under normal circumstances, StopIteration is caught by for loops or by explicit catches of StopIteration. If it doesn't get caught, *that's* an error, and it would be hidden if caught by a generic "except" clause. So, any code that is "broken" by the move was in fact *already* broken, it's just that one bug (a too-general except: clause) is masking the other bug (the escaping control-flow exception). >When a user creates their own exception for exiting multiple levels of >loops or frames, should they inherit from ControlFlowException on the >theory that it no different in intent from StopIteration or should they >inherit from UserError on the theory that it is a custom exception? Do >you really want routine control-flow exceptions to bypass "except >Exception". Yes, definitely. A control flow exception that isn't explicitly caught somewhere is itself an error, but it's not detectable if it's swallowed by an over-eager except: clause. > I suspect that will lead to coding errors that are very >difficult to spot (it sure looks like it should catch a StopIteration). Actually, no, it makes them *easy* to spot because nothing will catch them, and therefore you will be able to see that there's no handler in place. If they *are* caught, that is what leads to difficult-to-spot errors -- i.e. the situation we have now. >Be careful with these proposals. While well intentioned, they have >ramifications that aren't instantly apparent. Each one needs some deep >thought, user discussion, usability testing, and a darned good reason >for changing what we already have in the field. There is a darned good reason for this one; critical exceptions and control flow exceptions are pretty much the motivating reason for doing any changes to the exception hierarchy at all. ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
> > When a user creates their own exception for exiting multiple levels of > > loops or frames, should they inherit from ControlFlowException on the > > theory that it no different in intent from StopIteration or should they > > inherit from UserError on the theory that it is a custom exception? > > I say ControlFlowException. UserError is meant for quick-and-dirty > exception usage and not as a base for user error exceptions. If the > name is confusing it can be changed to SimpleError. Gads. It sounds like you're just making this up on the fly. The process should be disciplined, grounded in use cases, and aimed at known, real problems with the current hierarchy. The above question was rhetorical. It didn't have a right answer. "Quick-and-dirty" is not a useful category and cannot be reliably placed in one part of the tree versus another. A common and basic use case for quick and dirty exceptions is to break out of nested loops and functions. That is control flow as well as quick-and-dirty. 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On Aug 5, 2005, at 2:46 PM, Raymond Hettinger wrote: > The PEP moves StopIteration out from under Exception so that it cannot > be caught by a bare except or an explicit "except Exception". > > IMO, this is a mistake. In either form, a programmer is stating that > they want to catch and handle just about anything. There is a > reasonable argument that SystemExit special and should float to the > top, > but that is not the case with StopIteration. I'm glad you brought that up. I had wondered from the beginning why ControlFlowException was moved out, but thought there must be a good reason I was just not seeing, and promptly forgot about it. So now that I've been reminded, can someone explain to me why StopIteration and GeneratorExit should not be caught by an "except:" or "except Exception:" clause? James ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
[Raymond Hettinger wrote] > >The PEP moves StopIteration out from under Exception so that it cannot > >be caught by a bare except or an explicit "except Exception". > > > >IMO, this is a mistake. In either form, a programmer is stating that > >they want to catch and handle just about anything. There is a > >reasonable argument that SystemExit special and should float to the top, > >but that is not the case with StopIteration. [Phillip J. Eby] > While I agree with most of your -1's on gratuitous changes, this > particular > problem isn't gratuitous. A StopIteration that reaches a regular > exception > handler is a programming error; allowing StopIteration and other > control-flow exceptions to be caught other than explicitly *masks* > programming errors. Thanks for clearly articulating the rationale behind moving control-flow exceptions out from under Exception. The idea is not entirely without merit but I believe it is both misguided and has serious negative consequences. Two things are both true. Writers of bare excepts sometimes catch more than they intended and mask errors in their programs. It is also true that there are valid use cases for wanting to trap and log all recoverable errors in long running programs (i.e. not crashing your whole air traffic control system if submodule fails to trap a control flow exception). I favor the current setup for several reasons: 1. Writing a bare except is its own warning to a programmer. It is a Python basic to be careful with it and to focus attention on whether it is really intended. PyChecker flags it and it stands out during code review. IOW, it is a documented, well-understood hazard that should surprise no one. 2. There is a lesson to be taken from a story in the ACM risks forum where a massive phone outage was traced to a single line of C code that ran a "break" to get out of a nested if-statement. The interesting part is that this was known to be mission critical code yet the error survived multiple, independent code reviews. The problem was that the code created an optical illusion. We risk the same thing when an "except Exception" doesn't catch ControlFlowExceptions. The recovery/logging handler will look like it ought to catch everything, but it won't. That is a disaster for fault-tolerant coding and for keeping your sales demo from exploding in front of customers. 3. As noted above, there ARE valid use cases for bare excepts. Also consider that Python rarely documents or even can document all the recoverable exceptions that can be raised by a method call. A broad based handler is sometimes the programmer's only defense. 4. As noted in another email, user defined control flow exceptions are a key use case. I believe that was the typical use for string exceptions. The idea is that that user defined control flow exceptions are one of the key means for exiting multiple layers of loops or function calls. If you have a bunch of these, it is reasonable to expect that "except Exception" will catch them. Summary: It is a noble thought to save someone from shooting themselves in the foot with a bare except. However, bare excepts are clearly a we-are-all-adults construct. It has valid current use cases and its current meaning is likely the intended meaning. Making the change will break some existing code and produce dubious benefits. The change is at odds with fundamental use cases for user defined control flow exceptions. The change introduces the serious risk of a hard-to-spot optical illusion error where an "except Exception" doesn't catch exceptions that were intended to be caught. Nice try, but don't do anything this radical without validating that it solves significant problems without introducing worse, unintended effects. Don't break existing code unless there is a darned good reason. Check with the Zope and Twisted people to see if this would improve their lives or make things worse. There are user constituencies that are not being well represented in these discussions. 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Since I forgot to mention it in the last couple of messages - this version > looks very good. The transition strategy section makes it a lot more > meaningful. > Great to hear! > Brett Cannon wrote (in the PEP): > > Renamed Exceptions > > > > Renamed exceptions will directly subclass the new names. When the old > > exceptions are instantiated (which occurs when an exception is caught, > > either by a try statement or by propagating to the top of the execution > > stack), a PendingDeprecationWarning will be raised. > > Nice trick with figuring out how to raise the deprecation warning :) > (That line was going to read 'Why not just create an alias?', but then I > worked out what you were doing, and why you were doing it) > Thanks. > One case that this doesn't completely address is NameError, as it is the only > renamed exception which currently has a subclass. In this case, I think that > during the transmition phase, all three of the 'Unbound*Error' exceptions > should inherit from NameError, with NameError inheriting from NamespaceError. > > I believe it should still be possible to get the deprecation warning to work > correctly in this case (by not raising the warning when a subclass is > instantiated). > Ah, didn't think about that issue. Yeah, as long as you don't call a superclass' __init__ it should still work. > In the 'just a type' category, WeakReferenceError should still be under > StandardError in the hierarchy. > Yeah, that is an error from trying adding StandardError back in. -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote: > >+-- NamespaceError (rename of NameError) > >+-- UnboundFreeError (new) > >+-- UnboundGlobalError (new) > >+-- UnboundLocalError > > > > What are these new exceptions for? Under what circumstances are they > raised? Why is this necessary or an improvement? > Exceptions relating to when a name is not found in a specific namespace (directly related to bytecode). So UnboundFreeError is raised when the interpreter cannot find a variable that is a free variable. UnboundLocalError already exists. UnboundGlobalError is to prevent NameError from being overloaded. UnboundFreeError is to prevent UnboundLocalError from being overloaded > > Renamed Exceptions > > > > Renamed exceptions will directly subclass the new names. When the > > old exceptions are instantiated (which occurs when an exception is > > caught, either by a try statement or by propagating to the top of > > the execution stack), a PendingDeprecationWarning will be raised. > > > > This should properly preserve backwards-compatibility as old usage > > won't change and the new names can be used to also catch exceptions > > using the old name. The warning of the deprecation is also kept > > simple. > > This will cause problems when a library raises the exception under > the new name and an app tries to catch the old name. So the standard > lib (or any other lib) cannot raise the new names. Because the stdlib > must raise the old names, people will see the old names, continue > catching the old names, and the new names will never catch on. > Crap, you're right. Going to have to think about this more. > Perhaps it'd work out better to have the new names subclass the old > names. Then you have to continue catching the old name as long as > anyone is raising it, but at least you can raise the new name with > impunity. I expect not much code actually raises ReferenceError or > NameError besides that internal to python. Thus it would be > relatively safe to change all code to catch the new names for those > immediately. Lots of code raises RuntimeError, but I bet not very > much code explicitly catches it. > > Oh, but if the stdlib starts raising under the new names, that'll > break any code that checks the exact type of the exception against > the old name. Boo. > > It'd be better to somehow raise a DeprecationWarning upon access, yet > still result in the same object. Unfortunately I don't think there's > any way to do that in python. This lack of ability to deprecate > module attributes has bit me several times in other projects as well. > Matt Goodall wrote the hack attached at the end in order to move some > whole modules around in Nevow. Amazingly it actually seemed to > work. :) Something like that won't work for __builtins__, of course, > since that's accessed directly with PyDict_Get. > > All in all I don't really see a real need for these renamings and I > don't see a way to do them compatibly so I'm -1 to the whole idea of > renaming exceptions. > Well, the new names can go into 2.x but not removed until 3.0 . And there is always a solution. We do control the implementation so something has evil as hacking the exception system to do class-specific checks could work. > > Removal of Bare except Clauses > > > > A SemanticsWarning will be raised for all bare except clauses. > > Does this mean that bare except clauses change meaning to "except > Exception" immediately? Or (I hope) did you mean that in Py2.5 they > continue doing as they do now, but print a warning to tell you they > will be changing in the future? They would have a warning for a version, and then change. And this will nost necessarily go into 2.5 . -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > In general the PEP looks really good now! > Glad you like it. > On 8/4/05, Willem Broekema <[EMAIL PROTECTED]> wrote: > > On 8/4/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > OK, once the cron job comes around and is run, > > > http://www.python.org/peps/pep-0348.html will not be a 404 but be the > > > latest version of the PEP. > > > > Currently, when the "recursion limit" is reached, a RuntimeError is > > raised. RuntimeError is in the PEP renamed to UserError. UserError is > > in the new hierarchy located below StandardError, below Exception. > > > > I think that in the new hierarchy this error should be in the same > > "critical" category as MemoryError. (MemoryError includes general > > stack overflow.) > > No. Usually, a recursion error is a simple bug in the code, no > different from a TypeError or NameError etc. > > This does contradict my earlier claim that Python itself doesn't use > RuntimeError; I think I'd be happier if it remained RuntimeError. (I > think there are a few more uses of it inside Python itself; I don't > think it's worth inventing new exceptions for all these.) > OK, I will not propose renaming RuntimeError. -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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
Raymond Hettinger wrote: > 2. There is a lesson to be taken from a story in the ACM risks forum > where a massive phone outage was traced to a single line of C code that > ran a "break" to get out of a nested if-statement. The interesting part > is that this was known to be mission critical code yet the error > survived multiple, independent code reviews. The problem was that the > code created an optical illusion. We risk the same thing when an > "except Exception" doesn't catch ControlFlowExceptions. The > recovery/logging handler will look like it ought to catch everything, > but it won't. That is a disaster for fault-tolerant coding and for > keeping your sales demo from exploding in front of customers. I think that ControlFlowException should inherit from Exception, because it is an exception. As Raymond says, it's hard to spot this when in a hurry. But looking at the current PEP 348, why not rename BaseException to Exception and Exception to Error? That way, you could say "except Error:" instead of most of today's bare "except:" and it's clear that StopIteration or GeneratorExit won't be caught because they are not errors. Reinhold -- Mail address is perfectly valid! ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > While I agree with most of your -1's on gratuitous changes, this particular > problem isn't gratuitous. A StopIteration that reaches a regular exception > handler is a programming error; allowing StopIteration and other > control-flow exceptions to be caught other than explicitly *masks* > programming errors. And your point is? If that was the reasoning behind this PEP, it should move TypeError, NameError, AttributeError and a whole bunch of others (even LookupError) out of the StandardError hierarchy too! Those are all clear symptoms of programming errors and are frequently masked by bare 'except:'. The point is not to avoid bare 'except:' from hiding programming errors. There's no hope to obtain that goal. The point is to make *legitimate* uses of bare 'except:' easier -- the typical use case is an application that has some kind of main loop which uses bare 'except:' to catch gross programming errors in other parts of the app, or in code received from an imperfect source (like an end-user script) and recovers by logging the error and continuing. (I was going to say "or clean up and exit", but that use case is handled by 'finally:'.) Those legitimate uses often need to make a special case of Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not a bug in the code but a request from the user who is *running* the app (and the appropriate default response is to exit with a stack trace); SystemExit because it's not a bug but a deliberate attempt to exit the program -- logging an error would be a mistake. I think the use cases for moving other exceptions out of the way are weak; MemoryError and SystemError are exceedingly rare and I've never felt the need to exclude them; when GeneratorExit or StopIteration reach the outer level of an app, it's a bug like all the others that bare 'except:' WANTS to catch. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > This does contradict my earlier claim that Python itself doesn't use > RuntimeError; I think I'd be happier if it remained RuntimeError. (I > think there are a few more uses of it inside Python itself; I don't > think it's worth inventing new exceptions for all these.) > I just realized that keeping RuntimeError still does not resolve the issue that the name kind of sucks for realizing intrinsically that it is for quick-and-dirty exceptions (or am I the only one who thinks this?). Should we toss in a subclass called SimpleError? -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/5/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > This does contradict my earlier claim that Python itself doesn't use > > RuntimeError; I think I'd be happier if it remained RuntimeError. (I > > think there are a few more uses of it inside Python itself; I don't > > think it's worth inventing new exceptions for all these.) > > > > I just realized that keeping RuntimeError still does not resolve the > issue that the name kind of sucks for realizing intrinsically that it > is for quick-and-dirty exceptions (or am I the only one who thinks > this?). Should we toss in a subclass called SimpleError? I don't think so. People should feel free to use whatever pre-existing exception they like, even Exception. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [ Guido] > > One more thing. Is renaming NameError to NamespaceError really worth > > it? I'd say that NameError is just as clear. > > +1 on NameError -- it's clear, easy to type, isn't a gratuitous change, > and doesn't make you think twice about NamespaceError vs NameSpaceError. > OK, I will remove the name change proposal. -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
Re: [Python-Dev] Exception Reorg PEP checked in
Brett Cannon <[EMAIL PROTECTED]> wrote: > On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I just realized that keeping RuntimeError still does not resolve the > issue that the name kind of sucks for realizing intrinsically that it > is for quick-and-dirty exceptions (or am I the only one who thinks > this?). Should we toss in a subclass called SimpleError? Much Python code I've looked at uses ValueError for this purpose. Would adding a special exception add much utility? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> 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 ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > When a user creates their own exception for exiting multiple levels > of > > > loops or frames, should they inherit from ControlFlowException on > the > > > theory that it no different in intent from StopIteration or should > they > > > inherit from UserError on the theory that it is a custom exception? > > > > I say ControlFlowException. UserError is meant for quick-and-dirty > > exception usage and not as a base for user error exceptions. If the > > name is confusing it can be changed to SimpleError. > > Gads. It sounds like you're just making this up on the fly. The > process should be disciplined, grounded in use cases, and aimed at > known, real problems with the current hierarchy. > It is based on a real use case; my own. As I said in another email I just sent, I had no clue that RuntimeError was meant to be used as a generic exception until Guido pointed it out. -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
Re: [Python-Dev] [ python-Patches-790710 ] breakpoint command listsinpdb
> "Grégoire Dooms" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >This patch is about to celebrate its second birthday :-) > >What should I do to get it reviewed further ? > The guaranteed-by-a-couple-of-developers way is to review 5 other patches, > post a summary here, and name this as the one you want reviewed in > exchange. > TJR Speaking of the five-patch-review-rule, about two months ago I reviewed five patches and posted a summary here in order to push patch #1049855. This patch is still waiting for a verdict (this is also my own fault, since I needed several iterations to get this patch straightened out; my apologies for that). Is there anything else I can do for this patch? --Michiel. ___ 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
Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: [SNIP] > Those legitimate uses often need to make a special case of > Keyboardinterrupt and SystemExit -- KeyboardInterrupt because it's not > a bug in the code but a request from the user who is *running* the app > (and the appropriate default response is to exit with a stack trace); > SystemExit because it's not a bug but a deliberate attempt to exit the > program -- logging an error would be a mistake. > > I think the use cases for moving other exceptions out of the way are > weak; MemoryError and SystemError are exceedingly rare and I've never > felt the need to exclude them; when GeneratorExit or StopIteration > reach the outer level of an app, it's a bug like all the others that > bare 'except:' WANTS to catch. > So are you saying you would rather ditch all reorganization suggestions and just have SystemExit and KeyboardInterrupt inherit directly from BaseException, and keep the bare 'except' change and required superclass inheritance suggestions? Would this appease everyone else? If this is what people want, fine. But I am still going to suggest CriticalError stay since they are not caused by programmer error directly (I am ignoring C extension module screw-ups that devour memory). -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/5/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 8/5/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 8/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > > This does contradict my earlier claim that Python itself doesn't use > > > RuntimeError; I think I'd be happier if it remained RuntimeError. (I > > > think there are a few more uses of it inside Python itself; I don't > > > think it's worth inventing new exceptions for all these.) > > > > > > > I just realized that keeping RuntimeError still does not resolve the > > issue that the name kind of sucks for realizing intrinsically that it > > is for quick-and-dirty exceptions (or am I the only one who thinks > > this?). Should we toss in a subclass called SimpleError? > > I don't think so. People should feel free to use whatever pre-existing > exception they like, even Exception. > Fine, the idea is pulled. -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
Re: [Python-Dev] Exception Reorg PEP checked in
On 8/5/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > On 8/4/05, James Y Knight <[EMAIL PROTECTED]> wrote: > > > >+-- NamespaceError (rename of NameError) > > > >+-- UnboundFreeError (new) > > > >+-- UnboundGlobalError (new) > > > >+-- UnboundLocalError > > > > > > > > > > What are these new exceptions for? Under what circumstances are they > > > raised? Why is this necessary or an improvement? > > > > > > > Exceptions relating to when a name is not found in a specific > > namespace (directly related to bytecode). So UnboundFreeError is > > raised when the interpreter cannot find a variable that is a free > > variable. UnboundLocalError already exists. UnboundGlobalError is to > > prevent NameError from being overloaded. UnboundFreeError is to > > prevent UnboundLocalError from being overloaded > > Do we have any use cases for making the distinctions. I have NEVER had > a reason to write a different handler for the various types of > NameError. > > Also, everyone knows what a Global is. Can the same be said for Free? > I had thought that to be a implementation detail rather than part of the > language spec. > Perhaps then we should just ditch UnboundLocalError? If we just make sure we have good messages to go with the exceptions the reasons for the exception should be obvious. -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
Re: [Python-Dev] Exception Reorg PEP checked in
> > > > >+-- NamespaceError (rename of NameError) > > > > >+-- UnboundFreeError (new) > > > > >+-- UnboundGlobalError (new) > > > > >+-- UnboundLocalError > > > > > > > > > > > > > What are these new exceptions for? Under what circumstances are they > > > > raised? Why is this necessary or an improvement? [James Y Knight] > > > Exceptions relating to when a name is not found in a specific > > > namespace (directly related to bytecode). So UnboundFreeError is > > > raised when the interpreter cannot find a variable that is a free > > > variable. UnboundLocalError already exists. UnboundGlobalError is to > > > prevent NameError from being overloaded. UnboundFreeError is to > > > prevent UnboundLocalError from being overloaded [Raymond] > > Do we have any use cases for making the distinctions. I have NEVER had > > a reason to write a different handler for the various types of > > NameError. > > > > Also, everyone knows what a Global is. Can the same be said for Free? > > I had thought that to be a implementation detail rather than part of the > > language spec. [Brett] > Perhaps then we should just ditch UnboundLocalError? Perhaps the hierarchy should be left unchanged unless there is shown to be something wrong with it. "just ditching" something is not a rationale that warrants a language change. What problem is being solved by making additions or deletions to subclasses of NameError? > If we just make > sure we have good messages to go with the exceptions the reasons for > the exception should be obvious. +1 Raymodn ___ 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
