[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