Guido writes:
It would be simple enough to introduce new-style exceptions if Exception were made a new-style class and at the same time all new-style exceptions were required to derive from Exception:
raise x
would check whether x was:
- a string (but not an instance of a true subclass of str) - a classic class - an instance of a classic class - Exception or a subclass thereof - an instance of Exception or of a subclass thereof
Where the first three cases are for backward compatibility.
Similarly, the rule for
raise x, y
should allows x to be
- a string - a classic class - Exception or a subclass thereof
and in the last two cases, y could either be an instance of x (or of a subclass of x!), or an argument for x, or a tuple of arguments for x.
Okay, after hearing this (plus all the arguments about PEP 317 requiring an excessive level of migration pain), I am now convinced. If the PEP winds up being officially rejected, I propose that it grow a "rejection reasons" section explaing why, and that this section also describe the above plan as the "plausible alternative" to PEP 317 for eventual migration to new-style exceptions. -- Michael Chermside
If the PEP winds up being officially rejected, I propose that it grow a "rejection reasons" section explaing why, and that this section also describe the above plan as the "plausible alternative" to PEP 317 for eventual migration to new-style exceptions.
I strongly recommend doing that. I hereby officially reject PEP 317. --Guido van Rossum (home page: http://www.python.org/~guido/)
Quoth Guido van Rossum: [...]
I strongly recommend doing that. I hereby officially reject PEP 317.
Ok. I'll certainly add a section on the reasons, with discussion of the new-style exceptions question, and a summary of other feedback. [elsewhere in the thread]
I've now read the PEP, and it simply fails to explain why implicit instantiation sucks so badly as to require all this pain. The arguments of readability and consistency are pretty mild suckage IMO.
My next question, then, is whether those arguments are strong enough to justify, for example, recommending against implicit instantiation in PEP 8, or changing the Tutorial's examples. -- Steven Taschuk w_w staschuk@telusplanet.net ,-= U 1 1
I've now read the PEP, and it simply fails to explain why implicit instantiation sucks so badly as to require all this pain. The arguments of readability and consistency are pretty mild suckage IMO.
My next question, then, is whether those arguments are strong enough to justify, for example, recommending against implicit instantiation in PEP 8, or changing the Tutorial's examples.
I think not. This is something that each project may decide for itself. But I'm at most -0 on this. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wednesday 11 June 2003 06:30 pm, Guido van Rossum wrote:
I've now read the PEP, and it simply fails to explain why implicit instantiation sucks so badly as to require all this pain. The arguments of readability and consistency are pretty mild suckage IMO.
My next question, then, is whether those arguments are strong enough to justify, for example, recommending against implicit instantiation in PEP 8, or changing the Tutorial's examples.
I think not. This is something that each project may decide for itself. But I'm at most -0 on this.
An official recommendation (either way!) in the style guide would help -- particularly if the standard library was eventually edited to follow it. What's the added value of having, as e.g. is now the case in urllib.py, different statements within the same module such as: raise IOError(e.errno, e.strerror, e.filename) and then a few lines later: raise IOError, ('local file error', 'not on local host') ...? Seems a gratuitous (even though "pretty mild") 'suckage', as you put it. What's the objection to Pronouncing on one preferred style and putting it in the style guide? Alex
[Alex]
An official recommendation (either way!) in the style guide would help -- particularly if the standard library was eventually edited to follow it. What's the added value of having, as e.g. is now the case in urllib.py, different statements within the same module such as:
raise IOError(e.errno, e.strerror, e.filename)
and then a few lines later:
raise IOError, ('local file error', 'not on local host')
...? Seems a gratuitous (even though "pretty mild") 'suckage', as you put it. What's the objection to Pronouncing on one preferred style and putting it in the style guide?
The inconsistency you note in urllib.py is already frowned upon by the general style guideline "consistency with immediately surrounding code is valued more than consistency with the style guide". A pronouncement, no matter how mild, would mean that the other style is "wrong", and this would then cause a flurry of noise checkins of people trying to "fix" the "wrong" code, probably introducing some bugs in the hurry, if our experience with past flurries of style consistency checkins is any measure. I really don't think that raise IOError("message") should always be favored over raise IOError, "message" I find the latter a tad prettier (less punctuation!) even though the former is preferred when the message is too long to comfortably fit on a line. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I've now read the PEP, and it simply fails to explain why implicit instantiation sucks so badly as to require all this pain. The arguments of readability and consistency are pretty mild suckage IMO.
My next question, then, is whether those arguments are strong enough to justify, for example, recommending against implicit instantiation in PEP 8, or changing the Tutorial's examples.
I think not. This is something that each project may decide for itself. But I'm at most -0 on this.
The tutorial[1] implies but does not state that there are two syntaxes and implies but does not state that they are basically the same. Or one could get the implication that built-in exceptions use one syntax and user-defined ones use the other. I think that consistency is important to pedagogy and therefore feel that it should consistently use one syntax or the other. I wish Guido would pronounce that one is better than the other so that the software in the library could also migrate towards being pedagogically helpful. But if not, at least the tutorial can be internally consistent. Paul Prescod [1] http://www.python.org/doc/current/tut/node10.html
[Guido]
I think not. This is something that each project may decide for itself. But I'm at most -0 on this.
[Paul Prescod]
The tutorial[1] implies but does not state that there are two syntaxes and implies but does not state that they are basically the same. Or one could get the implication that built-in exceptions use one syntax and user-defined ones use the other.
I think that consistency is important to pedagogy and therefore feel that it should consistently use one syntax or the other. I wish Guido would pronounce that one is better than the other so that the software in the library could also migrate towards being pedagogically helpful. But if not, at least the tutorial can be internally consistent.
If there can be only one, then raise Exception() should be it.
Paul Prescod
I think parts of this were written at different times. It should either explain the equivalence between raise Foo, bar and raise Foo(bar) (without going into the subtleties of what happens when bar is a Foo instance or a tuple) or use the latter exclusively. But I think that it's fine at least to keep the examples that don't instantiate explicitly, maybe explaining that raise KeyboardError is short for raise KeyboardError() (again, without going into the details of how the system "knows" that -- that's not the task of the tutorial). --Guido van Rossum (home page: http://www.python.org/~guido/)
Quoth I: [... PEP 317 rejected ...]
I'll certainly add a section on the reasons, with discussion of the new-style exceptions question, and a summary of other feedback.
These additions have been made: http://www.python.org/peps/pep-0317.html#rejection (et seq.) If anyone feels that the additions omit or inadequately treat important points raised in the discussion, please let me know. (By email, please; no reason to trouble py-dev with such.) -- next-time-Gadget-<shakes fist>-ly yours, Steven Taschuk
participants (5)
-
Alex Martelli -
Guido van Rossum -
Michael Chermside -
Paul Prescod -
Steven Taschuk