Re: [Python-checkins] CVS: python/dist/src/Lib getopt.py,1.7,1.8

Guido van Rossum writes:
This breaks as soon as the standard exceptions are strings; does this mean -X will be removed in the next release? (Please????) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

"Fred" == Fred L Drake, Jr <fdrake@acm.org> writes:
Fred> This breaks as soon as the standard exceptions are Fred> strings; does this mean -X will be removed in the next Fred> release? (Please????) Pretty please? :)

[Fred Drake]
This breaks as soon as the standard exceptions are strings; does this mean -X will be removed in the next release? (Please????)
Not a bad idea. Anybody got a reason why -X should stay? (The next step would be to outlaw raise with a string argument; I think I can't make that for 1.6. But it would be a good idea to scan the standard library for string exceptions and convert all of them.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> Anybody got a reason why -X should stay? Kill it. Guido> (The next step would be to outlaw raise with a string Guido> argument; I think I can't make that for 1.6. But it would Guido> be a good idea to scan the standard library for string Guido> exceptions and convert all of them.) Or require that exception classes be derived from exceptions.Exception :) -Barry

[Barry]
Guido> Anybody got a reason why -X should stay?
Kill it.
You already said that. Anybody else?
That's hard to require. But it could easily be a requirement checked by one of the hypothetical typecheckers that are being discussed in the types-sig. --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
BAW> Or require that exception classes be derived from BAW> exceptions.Exception :) Guido> That's hard to require. But it could easily be a Guido> requirement checked by one of the hypothetical typecheckers Guido> that are being discussed in the types-sig. Hmm, the raise could probably enforce this, but it might not be that useful. -Barry

The raise could easily enforce this, but it would break lots of existing code. I wish I had done it right from the start -- then exceptions would have been classes from the start and would have required inheritance from the Exception base class. Like in Java. (And in C++?) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> The raise could easily enforce this, but it would break Guido> lots of existing code. Maybe not (I'm not sure). All the standard exceptions inherit from Exception, and of course there'd be nothing to enforce for existing user-defined string based exceptions. How pervasive are user-defined class based exceptions that don't inherit from Exception? (I don't know, and I haven't grepped, but I think we've been making that recommendation from day 1 of class-based standard exceptions, and I try to follow this recommendation in my own code). Guido> I wish I had done it right from the start -- then Guido> exceptions would have been classes from the start and would Guido> have required inheritance from the Exception base class. Guido> Like in Java. (And in C++?) All Hail, Python 2.0, our Savior and Redeemer! :) -Barry

From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Yes, but class-based user exceptions existed many Python versions before class-based standard exceptions! Two examples in the standard library: ConfigParser.py and xdrlib.py.
All Hail, Python 2.0, our Savior and Redeemer! :)
Or, the perfect excuse for procrastination :) (But yes, 2.0 will enforce this.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> Yes, but class-based user exceptions existed many Python Guido> versions before class-based standard exceptions! True, but I suspect that legacy class-based user exceptions are rare. I might be wrong, but you're absolutely right that these would all be broken. Guido> Two examples in the standard library: ConfigParser.py and Guido> xdrlib.py. Fortunately these are fixed with two 11 character patches :) I'm not necessarily arguing for or against tightening this. -Barry

Guido van Rossum writes:
I've seen this said or hinted at in a couple of places (the specific requirement that exception derive from Exception), but I've seen nothing that indicates any reason or derived value for this. Could someone please clarify? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

From: "Fred L. Drake, Jr." <fdrake@acm.org>
It's simply an extra bit of checking that your program is reasonable -- if you accidentally raise a non-exception class, there's probably something wrong with your program, and it gives the reader a hint about the intended use of the class. Other languages (e.g. Modula-3) have a specific exception type that can be used only for that one purpose. However it's useful to allow methods an subclassing of exceptions, so they might as well be classes. So, all exceptions are classes. But not all classes are exceptions. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
I'd say kill -X, but keep allowing string exceptions if it doesn't cost too much. I think of C++, like Gordon said. Also I'd take the chance and move the exceptions Python module back into the core, as a frozen mdule or whatever. Reason: At the moment, the CVS version of the Python library is incompatible to 1.5.2, which makes testing against the standard dist quite inconvenient. A compiled CVS Python does not run under PythonWin when I put it into my standard installation. Or is there an easy way to switch all settings to a completely different path? Anyway, I'm most probably off until Y2K. See ya all then, provided we survive - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home

I'd say kill -X, but keep allowing string exceptions if it doesn't cost too much. I think of C++, like Gordon said.
Agreed.
Point the PYTHONHOME variable to the top of your install directory. (On Windows you may have to kill the registry settings -- this is a bug.)
Anyway, I'm most probably off until Y2K.
Ditto.
See ya all then, provided we survive - chris
Best wishes to all, --Guido van Rossum (home page: http://www.python.org/~guido/)

Barry A. Warsaw writes:
Or require that exception classes be derived from exceptions.Exception :)
Ok, it's early, and maybe I haven't had enough coffee(!). But is this serious? Does JPython gain some benefit from this, is it your preference, or are you just yanking on my leg? ("Pulling my arm" as my 5-year-old says!) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

On Tue, 21 Dec 1999, Guido van Rossum wrote:
Kill it.
Keep string exceptions. I think there is probably a lot of code that still uses them. I know I do :-) We can issues warnings about string exceptions via the type-checking tool. Cheers, -g -- Greg Stein, http://www.lyra.org/

Guido van Rossum wrote:
This would be waaaaay to big a change for Python 1.x. There are alot of Python modules outside the standard distribution that use string exceptions. This would be a huge backward incompatability. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Guido van Rossum writes:
I don't know if requiring class-based exceptions will make the runtime any simpler, but that seems the only reason to do it. The only reason to remove -X, and possibly the string exception fallback code, is to ensure that we *can* subclass Exception and friends without having to catch TypeError and do something different. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Do what? *Require* class exceptions? You're probably right, and I think the gain is minimal. There's another reason to scan the std library though -- not to set a bad example. I want to eventually (in 2.0) move to a class-derived-from-Exception-only scheme.
And that's a very good reason indeed. Let me repeat my plans for 1.6. - Remove -X; the standard exceptions are always class-based. - Change all standard library and other example code to use class-based exceptions with a standard exception as base class, to set an example. - Still allow string exceptions in user code. - Still allow class exceptions that don't use a standard exception base class in user code. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Yes. Besides, I still think that string-based exceptions are just convenient for quick & dirty, throw-away test scripts.
Sounds okay. --- PS: I'm particularly happy today :-) because I've finally published the new version of our Web site http://www.inrialpes.fr. Two things I'd like to mention: (1) it shouldn't have been possible without quick Python scripts ;) (2) I'll find the time to reinvoke some of the topics discussed here instead of being mute as a fish. That said, Merry Christmas and a Happy New Year to all of you! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Vladimir.Marangozov@inrialpes.fr:
Yes. Besides, I still think that string-based exceptions are just convenient for quick & dirty, throw-away test scripts.
They have a hard-to-understand quirk though: the id() of the string is used to check rather than its value, so that except "foo" doesn't necessarily catch raise "foo"; but due to various optimization, this usually works, and people get bent out of shape when it doesn't. Since you have to give your exception a name, how hard is it to say class MyError(Exception): pass rathern than MyError = "MyError" ? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 22 Dec 1999, Guido van Rossum wrote:
It is very hard. My fingers do the typing for me, and they fill in strings. I'm trying to teach them otherwise, but they insist. You're also assuming that MyError gets defined. Sometimes, my little fingers like typing: try: foo except: raise "foo broke for some reason" Quick and dirty, indeed! :-) Happy Holidays, -g -- Greg Stein, http://www.lyra.org/

Guido van Rossum wrote:
Which brings 2 important questions: 1. In the long run, which one is better -- compare and check exceptions by reference (by name) or by value? (currently, this is done by reference on predefined object types: strings, classes or instances) I'd say, exceptions have to be compared (catched) by value, i.e. use "e1 == e2" instead of "e1 is e2". 2. Should we limit the exception "types"? I'd say, no. My Pythonic view of things says that we raise "objects", be they classes, instances, strings or, why not, ints. However, if one wants to put some order in the "unordered set" of exceptions s/he uses, then classes is the way to do it, because classes were given some nice properties, like inheritance, that allow to group and to organize logically the objects we throw and catch as exceptions (+ other bonus properties coming from classes). Note that conceptually, when we say "strings and ints", we have in mind "string instances and int instances", whose "classes" are written in C. When there will be String and Int classes of some sort as first class objects, then we'll fall back to the terminology: Exceptions can be classes or instances. If point 1 and (optionally) point 2 is implemented, the hard-to-understand quirk wouldn't be an issue and string-based exceptions would have a legal reason to stay and live.
You know what I think about "names"... I may have defined my exception conventions and be interested in catching an exception named 404, implying that "a 404 bobo" occured deeply in my code ("deeply in my code" meaning for example: database 4, service 0, customer group 4, or just a standard HTTP "Code 404 - Not Found".) Pushing this to the extreme to catapult your thoughts into the next millenium. :) and to emphasize the importance of discussing and anwsering objectively the above questions 1) and 2). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Guido> (The next step would be to outlaw raise with a string argument; I Guido> think I can't make that for 1.6. But it would be a good idea to Guido> scan the standard library for string exceptions and convert all Guido> of them.) Agreed. I know Zope uses (at least, my Zope-using code uses) stuff like raise 'Redirect', url to map names onto HTTP response codes. Makes it easier on people to remember names instead of numeric codes. I suspect it will take the Zopers awhile to convert to using class-based exceptions if they haven't already. (For all I know I may be using a deprecated feature.) Skip

"Fred" == Fred L Drake, Jr <fdrake@acm.org> writes:
Fred> This breaks as soon as the standard exceptions are Fred> strings; does this mean -X will be removed in the next Fred> release? (Please????) Pretty please? :)

[Fred Drake]
This breaks as soon as the standard exceptions are strings; does this mean -X will be removed in the next release? (Please????)
Not a bad idea. Anybody got a reason why -X should stay? (The next step would be to outlaw raise with a string argument; I think I can't make that for 1.6. But it would be a good idea to scan the standard library for string exceptions and convert all of them.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> Anybody got a reason why -X should stay? Kill it. Guido> (The next step would be to outlaw raise with a string Guido> argument; I think I can't make that for 1.6. But it would Guido> be a good idea to scan the standard library for string Guido> exceptions and convert all of them.) Or require that exception classes be derived from exceptions.Exception :) -Barry

[Barry]
Guido> Anybody got a reason why -X should stay?
Kill it.
You already said that. Anybody else?
That's hard to require. But it could easily be a requirement checked by one of the hypothetical typecheckers that are being discussed in the types-sig. --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
BAW> Or require that exception classes be derived from BAW> exceptions.Exception :) Guido> That's hard to require. But it could easily be a Guido> requirement checked by one of the hypothetical typecheckers Guido> that are being discussed in the types-sig. Hmm, the raise could probably enforce this, but it might not be that useful. -Barry

The raise could easily enforce this, but it would break lots of existing code. I wish I had done it right from the start -- then exceptions would have been classes from the start and would have required inheritance from the Exception base class. Like in Java. (And in C++?) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> The raise could easily enforce this, but it would break Guido> lots of existing code. Maybe not (I'm not sure). All the standard exceptions inherit from Exception, and of course there'd be nothing to enforce for existing user-defined string based exceptions. How pervasive are user-defined class based exceptions that don't inherit from Exception? (I don't know, and I haven't grepped, but I think we've been making that recommendation from day 1 of class-based standard exceptions, and I try to follow this recommendation in my own code). Guido> I wish I had done it right from the start -- then Guido> exceptions would have been classes from the start and would Guido> have required inheritance from the Exception base class. Guido> Like in Java. (And in C++?) All Hail, Python 2.0, our Savior and Redeemer! :) -Barry

From: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Yes, but class-based user exceptions existed many Python versions before class-based standard exceptions! Two examples in the standard library: ConfigParser.py and xdrlib.py.
All Hail, Python 2.0, our Savior and Redeemer! :)
Or, the perfect excuse for procrastination :) (But yes, 2.0 will enforce this.) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
Guido> Yes, but class-based user exceptions existed many Python Guido> versions before class-based standard exceptions! True, but I suspect that legacy class-based user exceptions are rare. I might be wrong, but you're absolutely right that these would all be broken. Guido> Two examples in the standard library: ConfigParser.py and Guido> xdrlib.py. Fortunately these are fixed with two 11 character patches :) I'm not necessarily arguing for or against tightening this. -Barry

Guido van Rossum writes:
I've seen this said or hinted at in a couple of places (the specific requirement that exception derive from Exception), but I've seen nothing that indicates any reason or derived value for this. Could someone please clarify? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

From: "Fred L. Drake, Jr." <fdrake@acm.org>
It's simply an extra bit of checking that your program is reasonable -- if you accidentally raise a non-exception class, there's probably something wrong with your program, and it gives the reader a hint about the intended use of the class. Other languages (e.g. Modula-3) have a specific exception type that can be used only for that one purpose. However it's useful to allow methods an subclassing of exceptions, so they might as well be classes. So, all exceptions are classes. But not all classes are exceptions. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
I'd say kill -X, but keep allowing string exceptions if it doesn't cost too much. I think of C++, like Gordon said. Also I'd take the chance and move the exceptions Python module back into the core, as a frozen mdule or whatever. Reason: At the moment, the CVS version of the Python library is incompatible to 1.5.2, which makes testing against the standard dist quite inconvenient. A compiled CVS Python does not run under PythonWin when I put it into my standard installation. Or is there an easy way to switch all settings to a completely different path? Anyway, I'm most probably off until Y2K. See ya all then, provided we survive - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home

I'd say kill -X, but keep allowing string exceptions if it doesn't cost too much. I think of C++, like Gordon said.
Agreed.
Point the PYTHONHOME variable to the top of your install directory. (On Windows you may have to kill the registry settings -- this is a bug.)
Anyway, I'm most probably off until Y2K.
Ditto.
See ya all then, provided we survive - chris
Best wishes to all, --Guido van Rossum (home page: http://www.python.org/~guido/)

Barry A. Warsaw writes:
Or require that exception classes be derived from exceptions.Exception :)
Ok, it's early, and maybe I haven't had enough coffee(!). But is this serious? Does JPython gain some benefit from this, is it your preference, or are you just yanking on my leg? ("Pulling my arm" as my 5-year-old says!) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

On Tue, 21 Dec 1999, Guido van Rossum wrote:
Kill it.
Keep string exceptions. I think there is probably a lot of code that still uses them. I know I do :-) We can issues warnings about string exceptions via the type-checking tool. Cheers, -g -- Greg Stein, http://www.lyra.org/

Guido van Rossum wrote:
This would be waaaaay to big a change for Python 1.x. There are alot of Python modules outside the standard distribution that use string exceptions. This would be a huge backward incompatability. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Guido van Rossum writes:
I don't know if requiring class-based exceptions will make the runtime any simpler, but that seems the only reason to do it. The only reason to remove -X, and possibly the string exception fallback code, is to ensure that we *can* subclass Exception and friends without having to catch TypeError and do something different. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Do what? *Require* class exceptions? You're probably right, and I think the gain is minimal. There's another reason to scan the std library though -- not to set a bad example. I want to eventually (in 2.0) move to a class-derived-from-Exception-only scheme.
And that's a very good reason indeed. Let me repeat my plans for 1.6. - Remove -X; the standard exceptions are always class-based. - Change all standard library and other example code to use class-based exceptions with a standard exception as base class, to set an example. - Still allow string exceptions in user code. - Still allow class exceptions that don't use a standard exception base class in user code. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Yes. Besides, I still think that string-based exceptions are just convenient for quick & dirty, throw-away test scripts.
Sounds okay. --- PS: I'm particularly happy today :-) because I've finally published the new version of our Web site http://www.inrialpes.fr. Two things I'd like to mention: (1) it shouldn't have been possible without quick Python scripts ;) (2) I'll find the time to reinvoke some of the topics discussed here instead of being mute as a fish. That said, Merry Christmas and a Happy New Year to all of you! -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Vladimir.Marangozov@inrialpes.fr:
Yes. Besides, I still think that string-based exceptions are just convenient for quick & dirty, throw-away test scripts.
They have a hard-to-understand quirk though: the id() of the string is used to check rather than its value, so that except "foo" doesn't necessarily catch raise "foo"; but due to various optimization, this usually works, and people get bent out of shape when it doesn't. Since you have to give your exception a name, how hard is it to say class MyError(Exception): pass rathern than MyError = "MyError" ? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 22 Dec 1999, Guido van Rossum wrote:
It is very hard. My fingers do the typing for me, and they fill in strings. I'm trying to teach them otherwise, but they insist. You're also assuming that MyError gets defined. Sometimes, my little fingers like typing: try: foo except: raise "foo broke for some reason" Quick and dirty, indeed! :-) Happy Holidays, -g -- Greg Stein, http://www.lyra.org/

Guido van Rossum wrote:
Which brings 2 important questions: 1. In the long run, which one is better -- compare and check exceptions by reference (by name) or by value? (currently, this is done by reference on predefined object types: strings, classes or instances) I'd say, exceptions have to be compared (catched) by value, i.e. use "e1 == e2" instead of "e1 is e2". 2. Should we limit the exception "types"? I'd say, no. My Pythonic view of things says that we raise "objects", be they classes, instances, strings or, why not, ints. However, if one wants to put some order in the "unordered set" of exceptions s/he uses, then classes is the way to do it, because classes were given some nice properties, like inheritance, that allow to group and to organize logically the objects we throw and catch as exceptions (+ other bonus properties coming from classes). Note that conceptually, when we say "strings and ints", we have in mind "string instances and int instances", whose "classes" are written in C. When there will be String and Int classes of some sort as first class objects, then we'll fall back to the terminology: Exceptions can be classes or instances. If point 1 and (optionally) point 2 is implemented, the hard-to-understand quirk wouldn't be an issue and string-based exceptions would have a legal reason to stay and live.
You know what I think about "names"... I may have defined my exception conventions and be interested in catching an exception named 404, implying that "a 404 bobo" occured deeply in my code ("deeply in my code" meaning for example: database 4, service 0, customer group 4, or just a standard HTTP "Code 404 - Not Found".) Pushing this to the extreme to catapult your thoughts into the next millenium. :) and to emphasize the importance of discussing and anwsering objectively the above questions 1) and 2). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Guido> (The next step would be to outlaw raise with a string argument; I Guido> think I can't make that for 1.6. But it would be a good idea to Guido> scan the standard library for string exceptions and convert all Guido> of them.) Agreed. I know Zope uses (at least, my Zope-using code uses) stuff like raise 'Redirect', url to map names onto HTTP response codes. Makes it easier on people to remember names instead of numeric codes. I suspect it will take the Zopers awhile to convert to using class-based exceptions if they haven't already. (For all I know I may be using a deprecated feature.) Skip
participants (10)
-
Barry A. Warsaw
-
Barry A. Warsaw
-
Christian Tismer
-
Fred L. Drake, Jr.
-
Gordon McMillan
-
Greg Stein
-
Guido van Rossum
-
Jim Fulton
-
Skip Montanaro
-
Vladimir Marangozov