On Dec 31, 2019, at 08:03, Richard Damon <[email protected]> wrote:
>
> IF I were to change the syntax ( which I don't propose), I believe the
> construct like foo or bar or baz in foobar to give you issues parsing. An
> alternative which is, in my opinion, more readable would be if any(foo, bar,
> baz) in foobar (and the alternative if all(foo, bar, baz) in foobar).
But any(foo, bar, baz) already has a meaning (and so does all), so this is
already valid but with the wrong result. Giving the exact same code a second
meaning is obviously ambiguous. And there doesn’t seem to be any obvious way
that either the any function or the compiler could resolve that ambiguity
without reading your mind.
That’s really the same problem the OP’s proposal already has. If the proposed
syntax were an error today it might be conceivable to give it a new meaning,
but it already has a meaning, so giving it a second one makes it ambiguous.
Notice that you can actually use any here, although it’s not quite as simple as
you want:
if any(thing in foobar for thing in (foo, bar, has)):
Maybe looking for a way to shorten that generator expression is worth pursuing,
but I can’t think of anything obvious that makes sense.
> To do this any and all could make a specially tagged tupl which interacts
> with operators like 'in' in a special way where it applies each of its
> members and or/ands the results.
>
> It may even be possible to do this with the existing Python by defining a
> suitable class any and all with an appropriate constructor and implementing
> its own version of things like in. (not sure if we can override 'is')
No, you can’t override is. And you can override in, but only from the container
side, not the element side. Most other operators do have a “reversed” method
(like __radd__ for overriding + from the left or just __gt__ for overriding <
from the left), but even that will only fire if the right side doesn’t know how
to handle the left side’s type or if the left side is an instance if a subclass
of the right side’s type.
And I don’t think you’d want these classes to be “magical” things that can
override operators in a way that you couldn’t write yourself, so the only way
to make this proposal work is to change the entire operator data model in a
pretty drastic way.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/6K4JH3JWZSKHW7BO7CTFHGMXJUAAH7WZ/
Code of Conduct: http://python.org/psf/codeofconduct/
