
On 12/31/19 12:49 PM, Andrew Barnert via Python-ideas wrote:
On Dec 31, 2019, at 08:03, Richard Damon <Richard@damon-family.org> 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. Yes, I forgot that any and all are already defined by Python. 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.
maybe it could be if (foo, bar, baz) any in foobar: since that is (I believe currently an error), but I agree it isn't that great of a syntax. I suspect this is really a maybe 'nifty' solution looking for a real problem, as you show, the generator expression really is a clean way to do it, and not THAT verbose.
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.
Ok, so you can't implement this with Python as it is. -- Richard Damon