Mailman 3 August 2005 - Python-Dev

Major revision of PEP 348 committed
by Brett Cannon 09 Aug '05

09 Aug '05

Version 1.5 of PEP 348 (http://www.python.org/peps/pep-0348.html) just got checked in. This one is a *big* change compared to the previous version: * Renamings removed * SystemExit are the KeyboardInterrupt are the only exceptions *not* inheriting from Exception + CriticalException has been renamed TerminalException so it is more inline with the idea that the exceptions are meant to terminate the interpreter, not that they are more critical than other exceptions * Removed ControlFlowException + StopIteration and GeneratorExit inherit from Exception directly * Added VMError which inherits Exception + SystemError and MemoryError subclass VMError * Removed UnboundG(Global|Free)Error * other stuff I don't remember This version addresses everyone's worries about backwards-compatibility or changes that were not substantive enough to break code. The things I did on my own without thorough discussion is remove ControlFlowException and introduce VMError. The former seemed reasonable since catching control flow exceptions as a group is probably rare and with StopIteration and GeneratorExit not falling outside of Exception, ControlFlowException lost its usefulness. VMError was introduced to allow the grouping of MemoryError and SystemError since they are both exceptions relating to the VM. The name can be changed to InterpreterError, but VMError is shorter while still getting the idea across. Plus I just like VMError more. =) OK, guys, have at it. -Brett

6 8

PEP: Generalised String Coercion
by Neil Schemenauer 09 Aug '05

09 Aug '05

The title is perhaps a little too grandiose but it's the best I could think of. The change is really not large. Personally, I would be happy enough if only %s was changed and the built-in was not added. Please comment. Neil PEP: 349 Title: Generalised String Coercion Version: $Revision: 1.2 $ Last-Modified: $Date: 2005/08/06 04:05:48 $ Author: Neil Schemenauer <nas(a)arctrix.com> Status: Draft Type: Standards Track Content-Type: text/plain Created: 02-Aug-2005 Post-History: 06-Aug-2005 Python-Version: 2.5 Abstract This PEP proposes the introduction of a new built-in function, text(), that provides a way of generating a string representation of an object without forcing the result to be a particular string type. In addition, the behavior %s format specifier would be changed to call text() on the argument. These two changes would make it easier to write library code that can be used by applications that use only the str type and by others that also use the unicode type. Rationale Python has had a Unicode string type for some time now but use of it is not yet widespread. There is a large amount of Python code that assumes that string data is represented as str instances. The long term plan for Python is to phase out the str type and use unicode for all string data. Clearly, a smooth migration path must be provided. We need to upgrade existing libraries, written for str instances, to be made capable of operating in an all-unicode string world. We can't change to an all-unicode world until all essential libraries are made capable for it. Upgrading the libraries in one shot does not seem feasible. A more realistic strategy is to individually make the libraries capable of operating on unicode strings while preserving their current all-str environment behaviour. First, we need to be able to write code that can accept unicode instances without attempting to coerce them to str instances. Let us label such code as Unicode-safe. Unicode-safe libraries can be used in an all-unicode world. Second, we need to be able to write code that, when provided only str instances, will not create unicode results. Let us label such code as str-stable. Libraries that are str-stable can be used by libraries and applications that are not yet Unicode-safe. Sometimes it is simple to write code that is both str-stable and Unicode-safe. For example, the following function just works: def appendx(s): return s + 'x' That's not too surprising since the unicode type is designed to make the task easier. The principle is that when str and unicode instances meet, the result is a unicode instance. One notable difficulty arises when code requires a string representation of an object; an operation traditionally accomplished by using the str() built-in function. Using str() makes the code not Unicode-safe. Replacing a str() call with a unicode() call makes the code not str-stable. Using a string format almost accomplishes the goal but not quite. Consider the following code: def text(obj): return '%s' % obj It behaves as desired except if 'obj' is not a basestring instance and needs to return a Unicode representation of itself. In that case, the string format will attempt to coerce the result of __str__ to a str instance. Defining a __unicode__ method does not help since it will only be called if the right-hand operand is a unicode instance. Using a unicode instance for the right-hand operand does not work because the function is no longer str-stable (i.e. it will coerce everything to unicode). Specification A Python implementation of the text() built-in follows: def text(s): """Return a nice string representation of the object. The return value is a basestring instance. """ if isinstance(s, basestring): return s r = s.__str__() if not isinstance(r, basestring): raise TypeError('__str__ returned non-string') return r Note that it is currently possible, although not very useful, to write __str__ methods that return unicode instances. The %s format specifier for str objects would be changed to call text() on the argument. Currently it calls str() unless the argument is a unicode instance (in which case the object is substituted as is and the % operation returns a unicode instance). The following function would be added to the C API and would be the equivalent of the text() function: PyObject *PyObject_Text(PyObject *o); A reference implementation is available on Sourceforge [1] as a patch. Backwards Compatibility The change to the %s format specifier would result in some % operations returning a unicode instance rather than raising a UnicodeDecodeError exception. It seems unlikely that the change would break currently working code. Alternative Solutions Rather than adding the text() built-in, if PEP 246 were implemented then adapt(s, basestring) could be equivalent to text(s). The advantage would be one less built-in function. The problem is that PEP 246 is not implemented. Fredrik Lundh has suggested [2] that perhaps a new slot should be added (e.g. __text__), that could return any kind of string that's compatible with Python's text model. That seems like an attractive idea but many details would still need to be worked out. Instead of providing the text() built-in, the %s format specifier could be changed and a string format could be used instead of calling text(). However, it seems like the operation is important enough to justify a built-in. Instead of providing the text() built-in, the basestring type could be changed to provide the same functionality. That would possibly be confusing behaviour for an abstract base type. Some people have suggested [3] that an easier migration path would be to change the default encoding to be UTF-8. Code that is not Unicode safe would then encode Unicode strings as UTF-8 and operate on them as str instances, rather than raising a UnicodeDecodeError exception. Other code would assume that str instances were encoded using UTF-8 and decode them if necessary. While that solution may work for some applications, it seems unsuitable as a general solution. For example, some applications get string data from many different sources and assuming that all str instances were encoded using UTF-8 could easily introduce subtle bugs. References [1] http://www.python.org/sf/1159501 [2] http://mail.python.org/pipermail/python-dev/2004-September/048755.html [3] http://blog.ianbicking.org/illusive-setdefaultencoding.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

14 35

__traceback__ and reference cycles
by Armin Rigo 09 Aug '05

09 Aug '05

Hi all, There are various proposals to add an attribute on exception instances to store the traceback (see PEP 344). A detail not discussed, which I thought of historical interest only, is that today's exceptions try very hard to avoid reference cycles, in particular the cycle 'frame -> local variable -> traceback object -> frame' which was important for pre-GC versions of Python. A clause 'except Exception, e' would not create a local reference to the traceback, only to the exception instance. If the latter grows a __traceback__ attribute, it is no longer true, and every such except clause typically creates a cycle. Of course, we don't care, we have a GC -- do we? Well, there are cases where we do: see the attached program... In my opinion it should be considered a bug of today's Python that this program leaks memory very fast and takes longer and longer to run each loop (each loop takes half a second longer than the previous one!). (I don't know how this bug could be fixed, though.) Spoiling the fun of figuring out what is going on, the reason is that 'e_tb' creates a reference cycle involving the frame of __del__, which keeps a reference to 'self' alive. Python thinks 'self' was resurrected. The next time the GC runs, the cycle disappears, and the refcount of 'self' drops to zero again, calling __del__ again -- which gets resurrected again by a new cycle. Etc... Note that no cycle actually contains 'self'; they just point to 'self'. In summary, no X instance gets ever freed, but they all have their destructors called over and over again. Attaching a __traceback__ will only make this "bug" show up more often, as the 'except Exception, e' line in a __del__() method would be enough to trigger it. Not sure what to do about it. I just thought I should share these thoughts (I stumbled over almost this problem in PyPy). A bientot, Armin

6 9

PyTuple_Pack added references undocumented
by Edward C. Jones 07 Aug '05

07 Aug '05

According to the source code, PyTuple_Pack returns a new reference (it calls PyTuple_New). It also Py_INCREF's all the objects in the new tuple. Is this unusual behavior? None of these added references are documented in the API Reference Manual.

4 3

PEP 8: exception style
by A.M. Kuchling 07 Aug '05

07 Aug '05

PEP 8 doesn't express any preference between the two forms of raise statements: raise ValueError, 'blah' raise ValueError("blah") I like the second form better, because if the exception arguments are long or include string formatting, you don't need to use line continuation characters because of the containing parens. Grepping through the library code, the first form is in the majority, used roughly 60% of the time. Should PEP 8 take a position on this? If yes, which one? --amk

6 7

Re: [Python-Dev] [ python-Patches-790710 ] breakpoint command listsinpdb
by Michiel De Hoon 07 Aug '05

07 Aug '05

> "Grégoire Dooms" <dooms(a)info.ucl.ac.be> wrote in message > news:42F32EF7.6050208@info.ucl.ac.be... > >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.

2 1

PEP, take 2: Exception Reorganization for Python 3.0
by Brett Cannon 06 Aug '05

06 Aug '05

OK, having taken in all of the suggestions, here is another revision round. I think I still have a place or two I partially ignored people just because there was not a severe uproar and I still think the original idea is good (renaming RuntimeError, for instance). I also added notes on handling the transition and rejected idea. There is now only one open issue, which is whether ControlFlowException should be removed. And I am still waiting on a PEP number to be able to check this into CVS and push me to flesh out the references. =) -------------------------------------------------------------- PEP: XXX Title: Exception Reorganization for Python 3.0 Version: $Revision: 1.5 $ Last-Modified: $Date: 2005/06/07 13:17:37 $ Author: Brett Cannon <brett(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Jul-2005 Post-History: XX-XXX-XXX .. contents:: Abstract ======== Python, as of version 2.4, has 38 exceptions (including warnings) in the built-in namespace in a rather shallow hierarchy. This list of classes has grown over the years without a chance to learn from mistakes and cleaning up the hierarchy. This PEP proposes doing a reorganization for Python 3.0 when backwards-compatibility is not an issue. Along with this reorganization, adding a requirement that all objects passed to a ``raise`` statement must inherit from a specific superclass is proposed. Lastly, the removal of bare ``except`` class is suggested. Rationale ========= Exceptions are a critical part of Python. While exceptions are traditionally used to signal errors in a program, they have also grown to be used for flow control for things such as iterators. There importance is great. But the organization of the exception hierarchy is suboptimal. Mostly for backwards-compatibility reasons, the hierarchy has stayed very flat and old exceptions who usefulness have not been proven have been left in. Making exceptions more hierarchical would help facilitate exception handling by making catching exceptions using inheritance much more logical. This should also help lead to less errors from being too broad in what exceptions are caught in an ``except`` clause. A required superclass for all exceptions is also being proposed [Summary2004-08-01]_. By requiring any object that is used in a ``raise`` statement to inherit from a specific superclass, certain attributes (such as those laid out in PEP 344 [PEP344]_) can be guaranteed to exist. This also will lead to the planned removal of string exceptions. Lastly, bare ``except`` clauses are to be removed [XXX Guido's reply to my initial draft]_. 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. This leads to errors that can be hard to debug thanks to exceptions' sometimes unpredictable execution flow. It also causes ``except`` statements to follow the "explicit is better than implicit" tenant of Python [XXX]_. Philosophy of Reorganization ============================ There are several goals in this reorganization that defined the philosophy used to guide the work. One goal was to prune out unneeded exceptions. Extraneous exceptions should not be left in since it just serves to clutter the built-in namespace. Unneeded exceptions also dilute the importance of other exceptions by splitting uses between several exceptions when all uses should have been under a single exception. Another goal was to introduce any exceptions that were deemed needed to fill any holes in the hierarchy. Most new exceptions were done to flesh out the inheritance hierarchy to make it easier to catch a category of exceptions with a simpler ``except`` clause. Changing inheritance to make it more reasonable was a goal. As stated above, having proper inheritance allows for more accurate ``except`` statements when catching exceptions based on the inheritance tree. Lastly, any renaming to make an exception's use more obvious from its name was done. Having to look up what an exception is meant to be used for because the name does not proper reflect its usage is annoying and slows down debugging. Having a proper name also makes debugging easier on new programmers. But for simplicity of existing user's and for transitioning to Python 3.0, only exceptions whose names were fairly out of alignment with their stated purpose have been renamed. New Hierarchy ============= Exception +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new) +-- StopIteration +-- GeneratorExit +-- SystemExit +-- StandardError +-- AssertionError +-- SyntaxError +-- IndentationError +-- TabError +-- UserException (rename of RuntimeError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- LookupError +-- IndexError +-- KeyError +-- TypeError +-- AttributeError +-- EnvironmentError +-- OSError +-- IOError +-- EOFError (new inheritance) +-- ImportError +-- NotImplementedError (new inheritance) +-- NamespaceError (rename of NameError) +-- UnboundGlobalError (new) +-- UnboundLocalError +-- UnboundFreeError (new) +-- WeakReferenceError (rename of ReferenceError) +-- ValueError +-- Warning +-- UserWarning +-- AnyDeprecationWarning (new) +-- PendingDeprecationWarning +-- DeprecationWarning +-- SyntaxWarning +-- SemanticsWarning (rename of RuntimeWarning) +-- FutureWarning Differences Compared to Python 2.4 ================================== Changes to exceptions from Python 2.4 can take shape in three forms: removal, renaming, or change in their superclass. There are also new exceptions introduced in the proposed hierarchy. New Exceptions -------------- CriticalException ''''''''''''''''' The superclass for exceptions for which a severe error has occurred that one would not want to recover from. The name is meant to reflect the point that these exceptions are usually raised only when the interpreter should most likely be terminated. All classes that inherit from this class are raised when the virtual machine has a asynchronous exception to raise about its state. ControlFlowException '''''''''''''''''''' This exception exists as a superclass for all exceptions that directly deal with control flow. Inheriting from Exception instead of StandardError prevents them from being caught accidently when one wants to catch errors. The name, by not mentioning "Error", does not lead to one to confuse the subclasses as errors. UnboundGlobalError '''''''''''''''''' Raised when a global variable was not found. UnboundFreeError '''''''''''''''' Raised when a free variable is not found. AnyDeprecationWarning ''''''''''''''''''''' A common superclass for all deprecation-related exceptions. While having DeprecationWarning inherit from PendingDeprecationWarning was suggested because a DeprecationWarning can be viewed as a PendingDeprecationWarning that is happening now, the logic was not agreed upon by a majority. But since the exceptions are related, creating a common superclass is warranted. Removed Exceptions ------------------ WindowsError '''''''''''' Too OS-specific to be kept in the built-in exception hierarchy. Renamed Exceptions ------------------ RuntimeError '''''''''''' Renamed UserException. Meant for use as a generic exception to be used when one does not want to create a new exception class but do not want to raise an exception that might be caught based on inheritance, RuntimeError is poorly named. It's name in Python 2.4 seems to suggest an error that occurred at runtime, possibly an error in the VM. Renaming the exception to UserException more clearly states the purpose for the exception as quick-and-dirty exception for the user to use. The name also keeps it in line with UserWarning. ReferenceError '''''''''''''' Renamed WeakReferenceError. ReferenceError was added to the built-in exception hierarchy in Python 2.2 [exceptionsmodule]_. Taken directly from the ``weakref`` module, its name comes directly from its original name when it resided in the module. Unfortunately its name does not suggest its connection to weak references and thus deserves a renaming. NameError ''''''''' Renamed NamespaceError. While NameError suggests its common use, it is not entirely apparent. Making it more of a superclass for namespace-related exceptions warrants a renaming to make it abundantly clear its use. Plus the documentation of the exception module[XXX]_ states that it is actually meant for global names and not for just any exception. RuntimeWarning '''''''''''''' Renamed SemanticsWarning. RuntimeWarning is to represent semantic changes coming in the future. But while saying that affects "runtime" is true, flat-out stating it is a semantic change is much clearer, eliminating any possible association of "runtime" with the virtual machine specifically. Changed Inheritance ------------------- AttributeError '''''''''''''' Inherits from StandardError. Originally inheriting from NotImplementedError, AttributeError is typically raised because of the lack of an attribute which does not necessarily mean it was not implemented but just not set yet. Thus it has been decoupled from NotImplementedError. EOFError '''''''' Subclasses IOError. Since an EOF comes from I/O it only makes sense that it be considered an I/O error. Required Superclass for ``raise`` ================================= By requiring all objects passed to a ``raise`` statement inherit from a specific superclass, one is guaranteed that all exceptions will have certain attributes. If PEP 342 [PEP344]_ is accepted, the attributes outlined there will be guaranteed to be on all exceptions raised. This should help facilitate debugging by making the querying of information from exceptions much easier. The proposed hierarchy has Exception as the required class that one must inherit from. Implementation -------------- Enforcement is straight-forward. Modifying ``RAISE_VARARGS`` to do an inheritance check first before raising an exception should be enough. For the C API, all functions that set an exception will have the same inheritance check. Removal of Bare ``except`` Clauses ================================== One of Python's basic tenants is "explicit is better than implicit". Unfortunately a bare ``except`` clause implicitly states it should catch all exceptions. While useful as a way to catch all exceptions when any object can be raised, requiring a specific superclass be inherited in order to raise an object gives a single class to catch to cover all exceptions. With this in mind, the removal of bare ``except`` statements is justified. Implementation -------------- A simple change to the grammar is all that is needed for implementation. Transition Plan =============== Exception Hierarchy Changes --------------------------- New Exceptions '''''''''''''' New exceptions can simply be added to the built-in namespace. Any pre-existing objects with the same name will mask the new exceptions, preserving backwards-compatibility. 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. New Inheritance for Old Exceptions '''''''''''''''''''''''''''''''''' Using multiple inheritance to our advantage, exceptions whose inheritance has changed in such a way as for them to not necessarily be caught by pre-existing ``except`` clauses can be made backwards-compatible. By inheriting from both the new superclasses as well as the original superclasses existing ``except`` clauses will continue to work as before while allowing the new inheritance to be used for new clauses. A PendingDeprecationWarning will be raised based on whether the bytecode ``COMPARE_OP(10)`` results in an exception being caught that would not have under the new hierarchy. This will require hard-coding in the implementation of the bytecode. Removed Exceptions '''''''''''''''''' Exceptions scheduled for removal will be transitioned much like the old names of renamed exceptions. Upon instantiation a PendingDeprecationWarning will be raised stating the the exception is due to be removed by Python 3.0 . Required Superclass for ``raise`` --------------------------------- A SemanticsWarning will be raised when an object is passed to ``raise`` that does not have the proper inheritance. Removal of Bare ``except`` Clauses ---------------------------------- A PendingDeprecationWarning will be raised when a bare ``except`` clause is used. Rejected Ideas ============== Threads on python-dev discussing this PEP can be found at [XXX]_. 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". Renaming Exception to Raisable, StandardError to Exception ---------------------------------------------------------- While the naming makes sense and emphasizes the required superclass as what must be inherited from for raising an object, the naming is not required. Keeping the existing names minimizes code change to use the new names. DeprecationWarning Inheriting From PendingDeprecationWarning ------------------------------------------------------------ Originally proposed because a DeprecationWarning can be viewed as a PendingDeprecationWarning that is being removed in the next version. But enough people thought the inheritance could logically work the other way the idea was dropped. AttributeError Inheriting From TypeError or NameError ----------------------------------------------------- Viewing attributes as part of the interface of a type caused the idea of inheriting from TypeError. But that partially defeats the thinking of duck typing and thus was dropped. Inheriting from NameError was suggested because objects can be viewed as having their own namespace that the attributes lived in and when they are not found it is a namespace failure. This was also dropped as a possibility since not everyone shared this view. Removal of EnvironmentError --------------------------- Originally proposed based on the idea that EnvironmentError was an unneeded distinction, the BDFL overruled this idea [XXX]_. Introduction of MacError and UnixError -------------------------------------- Proposed to add symmetry to WindowsError, the BDFL said they won't be used enough [XXX]_. The idea of then removing WindowsError was proposed and accepted as reasonable, thus completely negating the idea of adding these exceptions. SystemError Subclassing SystemExit ---------------------------------- Proposed because a SystemError is meant to lead to a system exit, the idea was removed since CriticalException signifies this better. ControlFlowException Under StandardError ---------------------------------------- It has been suggested that ControlFlowException inherit from StandardError. This idea has been rejected based on the thinking that control flow exceptions are typically not desired to be caught in a generic fashion as StandardError will usually be used. Open Issues =========== Remove ControlFlowException? ---------------------------- It has been suggested that ControlFlowException is not needed. Since the desire to catch any control flow exception will be atypical, the suggestion is to just remove the exception and let the exceptions that inherited from it inherit directly from Exception. This still preserves the seperation from StandardError which is one of the driving factors behind the introduction of the exception. Acknowledgements ================ Thanks to Robert Brewer, Josiah Carlson, Nick Coghlan, Timothy Delaney, Jack Diedrich, Fred L. Drake, Jr., Philip J. Eby, Greg Ewing, James Y. Knight, MA Lemburg, Guido van Rossum, Stephen J. Turnbull and everyone else I missed for participating in the discussion. References ========== .. [PEP342] PEP 342 (Coroutines via Enhanced Generators) (http://www.python.org/peps/pep-0342.html) .. [PEP344] PEP 344 (Exception Chaining and Embedded Tracebacks) (http://www.python.org/peps/pep-0344.html) .. [exceptionsmodules] 'exceptions' module (http://docs.python.org/lib/module-exceptions.html) .. [Summary2004-08-01] python-dev Summary (An exception is an exception, unless it doesn't inherit from Exception) (http://www.python.org/dev/summary/2004-08-01_2004-08-15.html#an-exception-i…) .. [Summary2004-09-01] python-dev Summary (Cleaning the Exception House) (http://www.python.org/dev/summary/2004-09-01_2004-09-15.html#cleaning-the-e…) .. [python-dev1] python-dev email (Exception hierarchy) (http://mail.python.org/pipermail/python-dev/2004-August/047908.html) .. [python-dev2] python-dev email (Dangerous exceptions) (http://mail.python.org/pipermail/python-dev/2004-September/048681.html) Copyright ========= This document has been placed in the public domain.

12 42

FW: PEP 8: exception style
by Raymond Hettinger 06 Aug '05

06 Aug '05

> PEP 8 doesn't express any preference between the > two forms of raise statements: > raise ValueError, 'blah' > raise ValueError("blah") > > I like the second form better, because if the exception arguments are > long or include string formatting, you don't need to use line > continuation characters because of the containing parens. Grepping > through the library code, the first form is in the majority, used > roughly 60% of the time. > > Should PEP 8 take a position on this? If yes, which one? I we had to pick one, I would also choose the second form. But why bother inflicting our preference on others, both forms are readable so we won't gain anything by dictating a style. Raymond

2 1

Re: [Python-Dev] PEP 8: exception style
by Robert Brewer 06 Aug '05

06 Aug '05

A.M. Kuchling wrote: > PEP 8 doesn't express any preference between the > two forms of raise statements: > raise ValueError, 'blah' > raise ValueError("blah") > > I like the second form better, because if the exception arguments are > long or include string formatting, you don't need to use line > continuation characters because of the containing parens. Grepping > through the library code, the first form is in the majority, used > roughly 60% of the time. > > Should PEP 8 take a position on this? If yes, which one? I like the second form better, because even intermediate Pythonistas sometimes make a mistake between: raise ValueError, A and raise (ValueError, A) I'd like to see the first form removed in Python 3k, to help reduce the ambiguity. But PEP 8 taking a stand on it would be a good start for now. Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org

1 0

Re: [Python-Dev] Exception Reorg PEP checked in
by Brett Cannon 05 Aug '05

05 Aug '05

On 8/5/05, Raymond Hettinger <raymond.hettinger(a)verizon.net> wrote: > > On 8/4/05, James Y Knight <foom(a)fuhm.net> 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

2 1