Re: [Python-Dev] Exception Reorg PEP revised yet again
Brett Cannon [EMAIL PROTECTED] writes: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. I don't know how you've been grepping, but the Python api functions to raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so. Typically, WindowsErrors are raised when Win32 API functions fail. In the core extension modules, I find at least mmapmodule.c, posixmodule.c, _subprocess.c, and _winreg.c raising them. It may be a bit hidden, because the docs for _winreg mention only EnvironmentError, but they are wrong: C:\py Python 2.5a0 (#60, Jul 4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, blah) Traceback (most recent call last): File stdin, line 1, in ? WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Win32 has the FormatError() api to convert error codes into descriptions - these descriptions are very useful, as are the error codes when you catch errors in client code. I would say as long as the Python core contains win32 specific modules like _winreg WindowsError should stay. For the name, I have no preference but I see no need to change it. Thomas PS: For ctypes, it doesn't matter if WindowsError stays or not. No problem to invent my own WindowsError if it goes away. ___ 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 revised yet again
On 8/12/05, Thomas Heller [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] writes: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. I don't know how you've been grepping, but the Python api functions to raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so. Forgot to add that to the grep statement after I discovered that. Typically, WindowsErrors are raised when Win32 API functions fail. In the core extension modules, I find at least mmapmodule.c, posixmodule.c, _subprocess.c, and _winreg.c raising them. It may be a bit hidden, because the docs for _winreg mention only EnvironmentError, but they are wrong: C:\py Python 2.5a0 (#60, Jul 4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, blah) Traceback (most recent call last): File stdin, line 1, in ? WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Win32 has the FormatError() api to convert error codes into descriptions - these descriptions are very useful, as are the error codes when you catch errors in client code. I would say as long as the Python core contains win32 specific modules like _winreg WindowsError should stay. For the name, I have no preference but I see no need to change it. OK, then it will just stay as-is. People can expect an updated PEP sometime this weekend. -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 revised yet again
On Aug 9, 2005, at 7:15 PM, Raymond Hettinger wrote: The data gathered by Jack and Steven's research indicate that the number of cases where TerminatingException would be useful is ZERO. Try not to introduce a new builtin that no one will ever use. Try not to add a new word whose only function is to replace a two-word tuple (TOOWTDI). Try not to unnecessarily nest the tree (FITBN). Try not to propose solutions to problems that don't exist (PBP). I disagree. TerminatingException is useful. For the immediate future, I'd like to be able to write code like this (I'm assuming that except: means what it means now, because changing that for Py2.5 would be insane): try: TerminatingException except NameError: # compatibility with python 2.5 TerminatingException = (KeyboardInterrupt, SystemExit) try: foo except TerminatingException: raise except: print error message What this gets me: 1) easy backwards compatibility with earlier pythons which still have KeyboardInterrupt and SystemExit under Exception and don't provide TerminatingException 2) I still catch string exceptions, in case anyone raises one 3) Forward compatibility with pythons that add more types of terminating exceptions. 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] Exception Reorg PEP revised yet again
On Aug 10, 2005, at 7:45 PM, Raymond Hettinger wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. WindowsError is an important distinction because its error codes are to be interepreted as being from Microsoft's windows error code list. That is a useful meaning. PlatformError is completely meaningless. Whether or not Python should really be raising errors with error numbers from the MS error number list instead of translating them to standard error codes is another issue...but as long as it does so, it should do so using WindowsError. 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] Exception Reorg PEP revised yet again
On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote: Remember, the Exception reorganization is for Python 3.0/3k/whatever, not for 2.5 . Huh, I could *swear* we were talking about fixing things for 2.5...but I see at least the current version of the PEP says it's talking about 3.0. If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. And here I was hoping this was an actual proposal. Ah well, then. 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] Exception Reorg PEP revised yet again
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote: On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote: Remember, the Exception reorganization is for Python 3.0/3k/whatever, not for 2.5 . Huh, I could *swear* we were talking about fixing things for 2.5...but I see at least the current version of the PEP says it's talking about 3.0. If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. And why do you think it will never happen? Guido has already said publicly multiple times that the 2.x branch will not go past 2.9, so unless Python goes stale there will be a 3.0 release. Python 3.0 might not be around the corner, but will come eventually and this stuff needs to get done at some point. -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 revised yet again
On 8/11/05, James Y Knight [EMAIL PROTECTED] wrote: If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. You are wrong. So wrong. -- --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 revised yet again
[James Y Knight] Huh, I could *swear* we were talking about fixing things for 2.5...but I see at least the current version of the PEP says it's talking about 3.0. If that's true, this is hardly worth discussing as 3.0 is never going to happen anyways. And here I was hoping this was an actual proposal. Ah well, then. Whenever a 3.0 aimpoint is agreed upon, as much as possible will be introduced before then (pretty much everything that doesn't break code). Ideally, the final step to 3.0 will consist primary of dropping obsolete things that had been kept only for backwards compatibility. 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 revised yet again
WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. [Brett] I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. Isn't OSError already used for another purpose (non-platform dependent exceptions raised by the os module)? 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 revised yet again
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. [Brett] I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. Isn't OSError already used for another purpose (non-platform dependent exceptions raised by the os module)? Don't quite follow what that has to do with making WindowsError become os.WindowsError. Yes, OSError is meant for platform-agnostic OS errors by the os module, but how does that affect the proposed move of WindowsError? -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 revised yet again
Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. 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 revised yet again
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? -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 revised yet again
On Wed, Aug 10, 2005, Brett Cannon wrote: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Googling for windowserror python produces 800 hits. So yes, it does seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. -- 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 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 revised yet again
[Brett Cannon wrote] Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. Just a data point (not really following this thread): The PyWin32 sources raise WindowsError twice (one of them is win32\Demos\winprocess.py which is probably where subprocess got it from) an catches it in 11 places. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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 revised yet again
On 8/10/05, Aahz [EMAIL PROTECTED] wrote: On Wed, Aug 10, 2005, Brett Cannon wrote: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Googling for windowserror python produces 800 hits. So yes, it does seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. But Googling for attributeerror python turns up 94,700, a factor of over 118. OSError turns up 20,300 hits; a factor of 25. Even EnvironmentError turns up more at 5,610 and I would expect most people don't use this class directly that often. While 800 might seem large, it's puny compared to other exceptions. Plus, if you look at the first 10 hits, 4 are from PEP 348, one of which is the top hit. =) -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 revised yet again
[Brett] I can compromise to this if others prefer this alternative. Anybody else have an opinion? We're not opinion shopping -- we're looking for analysis. Py3.0 is not supposed to just a Python variant -- it is supposed to be better. It is not about making compromises -- it is about only making changes that are clear improvements. First, do no harm. It is an abuse of the PEP process to toss up one random idea after another with whimsical justifications, zero research, zero analysis of the implications, no respect for existing code, no recognition that the current design is somewhat successful, and contravention of basic design principles (Zen of Python). The only thing worse is wasting everyone's time by sticking to the proposals like glue when others take the time to think it through and offer sound reasons why the proposal is not a good idea. [Aahz] Googling for windowserror python produces 800 hits. So yes, it does seem to be widely used. I'm -0 on renaming; +1 on leaving things as-is. Well said. Squirreling WindowsError away in another namespace harms existing code, reduces clarity, and offers no offsetting gains. It is simply crummy design to take a multi-module, multi-application exception and push it down into a module namespace. +0 on renaming; +1 on leaving as-is. 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 revised yet again
There is a reason you listed writing a PEP on your own on the School of Hard Knocks list; it isn't easy. I am trying my best here. Hang in there. Do what you can to make sure we get a result we can live with. -- R ___ 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 revised yet again
Raymond Hettinger wrote: TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? Yes, to avoid the current overbroad inheritance of except Exception: by intercepting and reraising these two terminating exceptions. If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? No, TerminatingException makes it explicit to the reader what is going on - special handling is being applied to any exceptions that indicate the interpreter is expected to exit as a result of the exception. Using except (KeyboardInterrupt, SystemExit): is less explicit, as it relies on the reader knowing that these two exceptions share the common characteristic that they are generally meant to terminate the Python interpreter. Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The main benefits of TerminatingException lie in easing the transition to Py3k. After transition, except Exception: will already do the right thing. However, TerminatingException will still serve a useful documentational purpose, as it sums up in two words the key characteristic that caused KeyboardInterrupt and SystemExit to be moved out from underneath Exception. Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. I'm also concerned about this one. IMO, bare excepts in Python 3k should either not be allowed at all (use except BaseException: intead), or they should be synonyms for except BaseException:. Having a bare except that doesn't actually catch everything just seems wrong - and we already have style guides that say except Exception: is to be generally preferred over a bare except. Consenting adults and all that. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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 revised yet again
On 8/8/05, Raymond Hettinger [EMAIL PROTECTED] wrote: [Brett Cannon] At this point the only changes to the hierarchy are the addition of BaseException and TerminatingException, and the change of inheritnace for KeyboardInterrupt, SystemExit, and NotImplementedError. TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? The problem with existing code checking for this situation is that the situation itself is not the same as it will be if bare 'except's change:: try: ... except: ... except TerminatingException: ... has never really been possible before, but will be if the PEP goes forward. If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? Do we need a second way to do it? But what if we add other exceptions that don't inherit from Exception that was want to typically propagate up? Having a catch-all for exceptions that a bare 'except' will skip that is more explicit than ``except BaseException`` seems reasonable to me. As Nick said in another email, it provides a more obvoius self-documentation point to catch TerminatingException than ``(KeyboardInterrupt, SystemExit)``, plus you get some future-proofing on top of it in case we add more exceptions that are not caught by a bare 'except'. Doesn't the new meaning of Exception already offer a better idiom: try: suite() except Exception: log_or_recover() except: handle_terminating_exceptions() else: Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The PEP needs to address all of the above. Right now, it contains a definition rather than justification, research, and analysis. WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. I unfortunately forgot to add that the exception would be moved under os, so it would be more of a renaming than a removal. The reason I pulled it was that Guido said UnixError and MacError didn't belong, so why should WindowsError stay? Obviously there are backwards-compatibility issues with removing it, but why should we have this platform-specific thing in the built-in namespace? Nothing else is platform-specific in the language until you go into the stdlib. The language itself is supposed to be platform-agnostic, and yet here is this exception that is not meant to be used by anyone but by a specific OS. Seems like a contradiction to me. After the change, nothing would be better and many things would be worse. NotImplementedError --- Moving this is fine. Removing unnecessary nesting is a step forward. The PEP should list that as a justification. Yay, something uncontraversial! =) Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. This is Guido's thing. You will have to convince him of the change. I can flesh out the PEP to argue for which ever result he wants, but that part of the proposal is in there because Guido wanted it. I am just a PEP lackey in this case. =) And once that is settled I guess it is either time for pronouncement or it just sits there until Python 3.0 actually starts to come upon us. What happened to don't take this too
Re: [Python-Dev] Exception Reorg PEP revised yet again
[Brett] The problem with existing code checking for this situation is that the situation itself is not the same as it will be if bare 'except's change:: try: ... except: ... except TerminatingException: ... has never really been possible before, but will be if the PEP goes forward. That's not an improvement. The above code fragment should trigger a gag reflex indicating that something is wrong with the proposed default for a bare except. Having a catch-all for exceptions that a bare 'except' will skip that is more explicit than ``except BaseException`` seems reasonable to me. The data gathered by Jack and Steven's research indicate that the number of cases where TerminatingException would be useful is ZERO. Try not to introduce a new builtin that no one will ever use. Try not to add a new word whose only function is to replace a two-word tuple (TOOWTDI). Try not to unnecessarily nest the tree (FITBN). Try not to propose solutions to problems that don't exist (PBP). 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 revised yet again
[Brett Cannon] At this point the only changes to the hierarchy are the addition of BaseException and TerminatingException, and the change of inheritnace for KeyboardInterrupt, SystemExit, and NotImplementedError. TerminatingException The rationale for adding TerminatingException needs to be developed or reconsidered. AFAICT, there hasn't been an exploration of existing code bases to determine that there is going to be even minimal use of except TerminatingException. Are KeyboardInterrupt and SystemExit often caught together on the same line and handled in the same way? If so, isn't except TerminatingException less explicit, clear, and flexible than except (KeyboardInterrupt, SystemExit)? Do we need a second way to do it? Doesn't the new meaning of Exception already offer a better idiom: try: suite() except Exception: log_or_recover() except: handle_terminating_exceptions() else: Are there any benefits sufficient to warrant yet another new built-in? Does it also warrant violating FIBTN by introducing more structure? While I'm clear on why KeyboardInterrupt and SystemExit were moved from under Exception, it is not at all clear what problem is being solved by adding a new intermediate grouping. The PEP needs to address all of the above. Right now, it contains a definition rather than justification, research, and analysis. WindowsError This should be kept. Unlike module specific exceptions, this exception occurs in multiple places and diverse applications. It is appropriate to list as a builtin. Too O/S specific is not a reason for eliminating this. Looking at the codebase there does not appear to be a good substitute. Eliminating this one would break code, decrease clarity, and cause modules to grow competing variants. After the change, nothing would be better and many things would be worse. NotImplementedError --- Moving this is fine. Removing unnecessary nesting is a step forward. The PEP should list that as a justification. Bare excepts defaulting to Exception After further thought, I'm not as sure about this one and whether it is workable. The code fragment above highlights the issue. In a series of except clauses, each line only matches what was not caught by a previous clause. This is a useful and basic part of the syntax. It leaves a bare except to have the role of a final catchall (much like a default in C's switch-case). If one line uses except Exception, then a subsequence bare except should probably catch KeyboardInterrupt and SystemExit. Otherwise, there is a risk of creating optical illusion errors (code that looks like it should work but is actually broken). I'm not certain on this one, but the PEP does need to fully explore the implications and think-out the consequent usability issues. And once that is settled I guess it is either time for pronouncement or it just sits there until Python 3.0 actually starts to come upon us. What happened to don't take this too seriously, I'm just trying to get the ball rolling? This PEP or any Py3.0 PEP needs to sit a good while before pronouncement. Because 3.0 is not an active project, the PEP is unlikely to be a high priority review item by many of Python's best minds. It should not be stamped as accepted until they've had a chance to think it through. Because 3.0 is still somewhat ethereal, it is not reasonable to expect them to push aside their other work to look at this right now. The PEP needs to be kicked around on the newsgroup (naming and grouping discussions are easy and everyone will have an opinion). Also the folks with PyPy, BitTorrent, Zope, Twisted, IronPython, Jython, and such need to have a chance to have their say. Because of Py3.0's low visibility, these PEPs could easily slide through prematurely. Were the project imminent, it is likely that this PEP would have had significantly more discussion. Try not to get frustrated at these reviews. Because there was no research into existing code, working to solve known problems, evaluation of alternatives, or usability analysis, it is no surprise Sturgeon's Law would apply. Since Python has been around so long, it is also no surprise that what we have now is pretty good and that improvements won't be trivially easy to come by. 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
