Problem with Unittest:

[Terry Reedy]

Two emendations

"Terry Reedy" <tjreedy at udel.edu> wrote in message
news:AMadnT1A-6bDFVyjXTWcoQ at comcast.com...
>
> "Francis Avila" <francisgavila at yahoo.com> wrote in message
> news:vc2snuamt8cn1f at corp.supernews.com...
> >
> > 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).

This syntax is a holdover from string exceptions for things like:

MyExcept = 'MyException'
...
raise MyExcept, 'This loop is taking too long...'

It is needed now for backward compatibility, but when string
exceptions go, it will no longer be *needed*


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

You were more right.  Apparently, from reading RefMan 7.4, the test is
issubclass(class or instance.__class__, class_or_tuple).

The manual is not completely consistent: 4.2 says "Exceptions are
identified by string objects or class instances" whereas 6.9 says "If
the first object is an instance, the type of the exception is the
class of the instance".  7.4 then says "An object is compatible with
an exception if it is either the object that identifies the
exception..."  If it were really true that a class instance can
'identify' an exception, then 'except instance' should work, but it
does not, and so 4.2 seems to be wrong.

To me, the root problem is trying to explain two different exception
systems with one set of words.  An exception string indentifier and an
exception string value are both the same type: strings.  But an
exception class and an exception class instance are different types.
Calling a class and its instance an 'identifier' and a 'value' is
something of a stretch.  It certainly is a confusing overload of terms
that have other well-defined meanings in Python.

Terry J. Reedy