[PEAK] Permissions for class with __getitem__

Phillip J. Eby pje at telecommunity.com
Mon Feb 14 11:33:39 EST 2005


At 03:24 PM 2/14/05 +0100, Radek Kanovsky wrote:
>On Mon, Feb 14, 2005 at 08:39:35AM -0500, Phillip J. Eby wrote:
> > I need to keep option 1 open though, because in future there will be other
> > things you can use on the right side of 'in'/'not in', in order to do
> > pattern matching.
>
>There is some ambiguity or magic here from my point of view but my
>opinion may change :-) Generic functions are novelty for me.

I'm thinking about future features like:

     expr in Call.match( [isinstance], `inst`, `cls` in Const)

But I suppose the above could be written more like:

     Call.match(expr, `func`, `inst`, `cls`) \
         and func is isinstance and isinstance(cls,Const)

But of course this is more verbose.


> > So, maybe the fix would be to give form 1 priority over form 2, instead of
> > the other way around.  I don't remember why I made the priorities that way
> > anyway, except that it seemed like it would be more backward-compatible
> > with normal "in" expressions that way.
>
>Or remove form 2 and reserve 'in' for GF??? I haven't seen any usage of it 
>yet.

I think it would be confusing if this didn't work:

     x in ('a','b')

Right now, it translates to roughly the same thing as 'x=="a" or 
x=="b"'.  i.e., it's treated as a set of '==' tests.




More information about the PEAK mailing list