Mailing List Archive

>>>>> "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? :)

> Guido van Rossum writes:
> > +
> > + class GetoptError(Exception):
> > + opt = ''
> > + msg = ''
> > + def __init__(self, *args):
> > + self.args = args
> > + if len(args) == 1:
> > + self.msg = args[0]
> > + elif len(args) == 2:
> > + self.msg = args[0]
> > + self.opt = args[1]
> > +
> > + def __str__(self):
> > + return self.msg
> >
> > ! error = GetoptError # backward compatibility

[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?

> 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
> :)

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

> >>>>> "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>

> >>>>> "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).

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/)

On Tue, 21 Dec 1999, Guido van Rossum wrote:
>...
> [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?

Kill it.

> (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.)

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" == 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]

> 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++?)

In C++ you can throw anything at all. Strings, ints, that
Warsaw blockhead...

off-topic-ly y'rs

- Gordon

Guido van Rossum wrote:
>
> [Barry]
> > Guido> Anybody got a reason why -X should stay?
> >
> > Kill it.
>
> You already said that.
>
> Anybody else?

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.

> 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?

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/)

Guido van Rossum wrote:
>
> (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.)

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:
> (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.)

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

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

> From: "Fred L. Drake, Jr." <fdrake@acm.org>
>
> Guido van Rossum writes:
> > (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.)
>
> I don't know if requiring class-based exceptions will make the
> runtime any simpler, but that seems the only reason to do it.

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.

> 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.

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:
>
> [Fred Drake]
> > I don't know if requiring class-based exceptions will make the
> > runtime any simpler, but that seems the only reason to do it.
>
> Do what? *Require* class exceptions? You're probably right, and I
> think the gain is minimal.

Yes. Besides, I still think that string-based exceptions are just
convenient for quick & dirty, throw-away test scripts.

>
> 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.

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:
> 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"
>
> ?

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 writes:
> 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++?)

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>

> Guido van Rossum writes:
> > 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++?)
>
> 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?

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/)

> 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.

I sort-of use this feature when I'm debugging: if I want to know what happens
in an exception that is usually caught somewhere higher up in the call stack I
simply put quotes around the exception name and the exception will happen
uncaught. The same trick works for except: clauses.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

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