On 12/31/19 12:49 PM, Andrew Barnert via Python-ideas wrote:
On Dec 31, 2019, at 08:03, Richard Damon <rich...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QDW3PFZE7RJNZFIFBH4N7JITSCSRX4DT/
Code of Conduct: http://python.org/psf/codeofconduct/
