Why "class exceptions" are not deprecated?

rurpy at yahoo.com rurpy at yahoo.com
Thu Mar 23 00:27:40 CET 2006


Fredrik Lundh wrote:
> Gregory Petrosyan wrote:
>
> > 1) From 2.4.2 documentation:
> > There are two new valid (semantic) forms for the raise statement:
> > raise Class, instance
> > raise instance
> >
> > 2) In python:
> > >>> raise NameError
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > NameError
> > >>> help(NameError)
> > Help on class NameError in module exceptions: ...
> > >>> raise 0
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: exceptions must be classes, instances, or strings
> > (deprecated), not i
> > nt
> >
> > So, if it's a bug in documentation, it should be corrected. Otherwise,
> > (IMHO!) raising classes should be deprecated.
>
> it could be that the tutorial author expected you to read chapter 8
> before you read chapter 9, and used "new" to mean forms that hadn't
> already been described:
>
>     http://docs.python.org/tut/node10.html
>
> > Does raising class make sence? As for me, I can't find any usefull
> > case for it.
>
> as explained in the language reference,
>
>     raise Class
>
> is the same thing as
>
>     raise Class()

The OP points out an ambiguity in the docs, and as usual,
gets told he can't read, etc.  How typical.  Maybe if comments
like this were encouraged and acted upon, the docs would be
a little better than they are.  But I guess the current practice
of intimidation has benefits too in that it allows the response,
"nobody has complained, so the docs must be really great
and we can go on writing Python instead of that grungy
English."

And maybe if there were a decent language reference manual
people wouldn't be so inclined to use the Tutorial as one, with
the resultant out-of-sequence reading.




More information about the Python-list mailing list