Problem with Unittest:
Terry Reedy
tjreedy at udel.edu
Tue May 13 20:05:49 EDT 2003
"Francis Avila" <francisgavila at yahoo.com> wrote in message
news:vc2snuamt8cn1f at corp.supernews.com...
>
> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> news:88ycnaV9r5MLqlyjXTWcog at comcast.com...
> > Bad advice, I believe. When you raise an exception class, it is
> > converted to an exception instance which is tested against the
classes
> > listed in except statements with isinstance().
>
> But that seems completely backwards to me. I thought raising
instances was
> depreciated (ok, "discouraged") when we switched over to exception
classes
> instead of strings. And so now we raise classes instead of (for now
only
> conceptually) instances of string objects. It would seem instead
that
> raising *instances* (including all the now-builtin types) would be
> depreciated, and only classes could be raised, which are implicitly
> instantiated before being tossed up. Is the suggestion really that
every
> raise statement be
>
> raise Exception(arg)
This is how one creates a class instance everywhere else in Python,
and optionally here.
> instead of
>
> raise Exception, arg
This is the only place in Python where a class instance is created
with this syntax.
So yes, I would like to see this exceptional and unnecessary duplicate
syntax considered for deprecation (along with string exceptions).
> won't except statements *require* a class rather than a instance?
Except statements 'receive' a class instance which is checked against
the class-or-tuple with isinstance(instance, class-or-tuple). Again,
the exception object bound to the name you give after the ',' is the
instance, not its class. I find it easier to remember this if I
directly create the instance in the first place. The time saving of
typing ', ' instead of '(' and ')' is not, to me, worth the confusion.
> In any case, I was completely wrong about what the OP's problem was:
the
Yeah, this is off-topic, but I think he got enough on-topic advice to
move forward, at least to his next problem.
Terry J. Reedy
More information about the Python-list
mailing list