2.2 features

[Marcin 'Qrczak' Kowalczyk]

Wed, 1 Aug 2001 15:18:03 -0400, Steve Holden <sholden at holdenweb.com> pisze:

> What you seem to be requesting is that
> 
>     class <op> class => tuple_of_classes
>     class <op> tuple_of_classes => tuple_of_classes
>     tuple_of_classes <op> class => tuple_of_classes

Not tuple_of_classes but an object which behaves like union of these
classes for the purposes of testing instances.

> since in that case the tuple's __contains__ method will return the truth
> value you require.

It wouldn't. "x in tuple" doesn't check whether any element of the
tuple contains x, but whether any element is equal to x.

> The current syntax for multiple exception types surely means there's
> and implicit "exception in tuple" test?

No. For tuples it does this:
    for x in obj:
        if isinstance(exc, x):
            matches = 1
            break
    else:
        matches = 0
For classes it does this:
    matches isinstance(exc, obj)
It treats tuples and classes differently.

OTOH in the syntax I shown the test is performed polymorphically,
the object given in the except clause simply chooses how to do it
by providing its __contains__ (or rather tp_whatever slot).

It would imply that
    try:
        i = some_integer
        raise i
    except [1, 2]:
        do_this
    except [3, 4]:
        do_that
    except int:
        otherwise
would work, and using single numbers in except clauses wouldn't,
and if [] here are not considered too ugly it opens the door for
a "case" construct.

The current tuple syntax would mean a different thing after the
transition period when it's still special-cased, so I'm not convinced
that it's worth the trouble at all.

What I am convinced is that current rules for raise and except are
too complicated. I saw them written and I didn't remember them,
and it's not something which can be guessed.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK