2.2 features

[Steve Holden]

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn.pl.9mgfg4.hch.qrczak at qrnik.zagroda...
> Wed, 01 Aug 2001 09:15:27 -0700, Paul Prescod <paulp at ActiveState.com>
pisze:
>
> > Second, I think that this might be worth adding new syntax for one
> > reason. The current syntax for exception-type trapping is extremely
> > error prone and nasty and it is essentially the same problem. I
> > could imagine:
> >
> > try:
> >     foo()
> > except exc isa OverflowError, ZeroDivisionError:
> >     pass
>
> Instead of commas an operator could be used which produces an object
> whose __contains__ tests whether the given object belongs to either
> of arguments. Obvious candidates are | or +, so
>     try:
>         foo()
>     except OverflowError | ZeroDivisionError:
>         pass
> works and
>     if obj in (int | float)
> works using the same mechanism. Or maybe with + instead of |.
>
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

since in that case the tuple's __contains__ method will return the truth
value you require. The current syntax for multiple exception types surely
means there's and implicit "exception in tuple" test? Or am I missing
something?

If not it's hard to see the advantage of allowing such a construction when a
tuple already does what you want, and also removes syntactic ambiguity which
might otherwise occur due to operator precedence.

so-i'm-probably-missing-something-ly y'rs  - steve
--
http://www.holdenweb.com/