Re: [Python-Dev] PEP 348: Exception Reorganization for Python 3.0
Guido van Rossum wrote: > 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. To try to turn this idea into a concrete example, the idea would be to make the following code work correctly: for job in joblist: try: job.exec() except: # or "except Exception:" failed_jobs.append((job, sys.exc_info())) Currently, this code will make a user swear, as Ctrl-C will cause the program to move onto the next job, instead of exiting as you would except (I have found Python scripts not exiting when I press Ctrl-C to be an all-too-common problem). Additionally calling sys.exit() inside a job will fail. This may be deliberate (to prevent a job from exiting the whole application), but given only the code above, it looks like a bug. The program will attempt to continue in the face of a MemoryError. This is actually reasonable, as memory may have been freed as the stack unwound to the level of the job execution loop, or the request that failed may have been for a ridicuolously large amount of memory. The program will also attempt to continue in the face of a SystemError. This is reasonable too, as SystemError is only used when the VM thinks the current operation needs to be aborted due to an internal problem in the VM, but the VM itself is still safe to use. If the VM thinks something is seriously wrong with the internal data structures, it will kill the process with Py_FatalError (to ensure that no further Python code is executed), rather than raise SystemError. As others have pointed out, GeneratorExit and StopIteration should never reach the job execution loop - if they do, there's a bug in the job, and they should be caught and logged. That covers the six exceptions that have been proposed to be moved out from under "Exception", and, as I see it, only two of them end up making the grade - SystemExit and KeyboardInterrupt, for exactly the reasons Guido gives in his message above. This suggests a Py3k exception hierarchy that looks like: BaseException +-- CriticalException +-- SystemExit +-- KeyboardInterrupt +-- Exception +-- GeneratorExit +-- (Remainder as for Python 2.4, other than KeyboardInterrupt) With a transitional 2.x hierarchy that looks like: BaseException +-- CriticalException +-- SystemExit +-- KeyboardInterrupt +-- Exception +-- GeneratorExit +-- (Remainder exactly as for Python 2.4) The reason for the CriticalException parent is that Python 2.x code can be made 'correct' by doing: try: # whatever except CriticalException: raise except: # or 'except Exception' # Handle everything non-critical And, the hypothetical job execution loop above can be updated to: for job in joblist: try: job.exec() except CriticalException: failed_jobs.append((job, sys.exc_info())) job_idx = joblist.find(job) skipped_jobs.extend(joblist[job_idx+1:] raise except: # or "except Exception:" failed_jobs.append((job, sys.exc_info())) To tell the truth, if base except is kept around for Py3k, I would prefer to see it catch BaseException rather than Exception. Failing that, I would prefer to see it removed. Having it catch something other than the root of the exception hierarchy would be just plain confusing. Moving SystemExit and KeyboardInterrupt is the only change we've considered which seems to have a genuine motivating use case. The rest of the changes suggested don't seem to be solving an actual problem (or are solving a problem that is minor enough to be not worth any backward compatibility pain). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia -
[Python-Dev] PEP: Generalised String Coercion
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 <[EMAIL PROTECTED]>
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 w
[Python-Dev] PEP 8: exception style
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
___
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
[Nick Coghlan] > As others have pointed out, GeneratorExit and StopIteration should never > reach > the job execution loop - if they do, there's a bug in the job, and they > should > be caught and logged. Please read my other, detailed post on this (8/5/2005 4:05pm). It is a mistake to bypass control flow exceptions like GeneratorExit and StopIteration. Those need to remain under Exception. Focus on your core use case of eliminating the common idiom: try: block() except KeyboardInterrupt: raise except: pass# or some handler/logger In real code, I've never seen the above idiom used with StopIteration. Read Guido's note and my note. There are plenty of valid use cases for a bare except intending to catch almost everything including programming errors from NameError to StopIteration. It is a consenting-adults construct. Your proposal breaks a major use case for it (preventing your sales demos from crashing in front of your customers, writing fault-tolerant programs, etc.) 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 8: exception style
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
[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] PEP 8: exception style
On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> 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?
Definitely ValueError('blah'). The other form will go away in Python
3000. Please update the PEP.
--
--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
[Python-Dev] FW: PEP 8: exception style
> 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
___
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] FW: PEP 8: exception style
[AMK]
>> 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?
[Raymond Hettinger]
> 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.
Ongoing cruft reduction -- TOOWTDI. The first form was necessary at
Python's start because exceptions were strings, and strings aren't
callable, and there needed to be _some_ way to spell "and here's the
detail associated with the exception". "raise" grew special syntax to
support that need. In a Python without string exceptions, that syntax
isn't needed, and becomes (over time) an increasingly obscure way to
invoke an ordinary constructor -- ValueError("blah") does exactly the
same thing in a raise statement as it does in any other context, and
transforming `ValueError, 'blah'` into the former becomes a wart
unique to raise statements.
___
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 8: exception style
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> 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?
>
> Definitely ValueError('blah'). The other form will go away in Python
> 3000. Please update the PEP.
Great. PEP 3000 could also be updated to add the line
The raise Error,'blah' syntax: use raise Error('blah') instead [14]
in the To be removed section after the line on string exceptions and [14]
under references.
Terry J. Reedy
___
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] Generalised String Coercion
> PEP: 349 > Title: Generalised String Coercion ... > 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. This PEP strikes me as premature, as putting the toy wagon before the horse, since it is premised on a major change to Python, possibly the most disruptive and controversial ever, being a done deal. However there is, as far as I could find no PEP on Making Strings be Unicode, let alone a discussed, debated, and finalized PEP on the subject. > Clearly, a smooth migration path must be provided. Of course. But the path depends on the detailed final target, which has not, as far as I know, has been finalized, and certainly not in the needed PEP. Your proposal might be part of the transition section of such a PEP or of a separate migration path PEP. Terry J. Reedy ___ 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 8: exception style
On 8/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/6/05, A.M. Kuchling <[EMAIL PROTECTED]> 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?
>
> Definitely ValueError('blah'). The other form will go away in Python
> 3000. Please update the PEP.
>
Done. rev. 1.18 .
-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: > Please read my other, detailed post on this (8/5/2005 4:05pm). It is a > mistake to bypass control flow exceptions like GeneratorExit and > StopIteration. Those need to remain under Exception. This is the paragraph after the one you replied to above: [Nick Coghlan] >> That covers the six exceptions that have been proposed to be moved out >> from under "Exception", and, as I see it, only two of them end up making >> the grade - SystemExit and KeyboardInterrupt, for exactly the reasons >> Guido gives in his message above. The remainder of my message then goes on to describe a hierarchy just as you suggest - SystemError, MemoryError, StopIteration and GeneratorExit are all still caught by "except Exception:". The only two exceptions which are no longer caught by "except Exception:" are KeyboardInterrupt and SystemExit. 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] Generalised String Coercion
[Removed python-list CC] On 8/6/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > > PEP: 349 > > Title: Generalised String Coercion > ... > > 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. > > This PEP strikes me as premature, as putting the toy wagon before the > horse, since it is premised on a major change to Python, possibly the most > disruptive and controversial ever, being a done deal. However there is, as > far as I could find no PEP on Making Strings be Unicode, let alone a > discussed, debated, and finalized PEP on the subject. True. OTOH, Jython and IreonPython already have this, and it is my definite plan to make all strings Unicode in Python 3000. The rest (such as a bytes datatype) is details, as they say. :-) My first response to the PEP, however, is that instead of a new built-in function, I'd rather relax the requirement that str() return an 8-bit string -- after all, int() is allowed to return a long, so why couldn't str() be allowed to return a Unicode string? The main problem for a smooth Unicode transition remains I/O, in my opinion; I'd like to see a PEP describing a way to attach an encoding to text files, and a way to decide on a default encoding for stdin, stdout, stderr. -- --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 348: Exception Reorganization for Python 3.0
> The remainder of my message then goes on to describe a hierarchy just as > you > suggest - SystemError, MemoryError, StopIteration and GeneratorExit are > all > still caught by "except Exception:". The only two exceptions which are no > longer caught by "except Exception:" are KeyboardInterrupt and SystemExit. Ah, I was too quick on the draw. It now appears that you were already converted :-) Now, if only the PEP would get updated ... BTW, why did you exclude MemoryError? 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] Major revision of PEP 348 committed
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 ___ 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
