On Dec 31, 2019, at 11:50, MRAB <pyt...@mrabarnett.plus.com> wrote:
>
> On 2019-12-31 17:49, 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.
>> 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.
> An alternative syntax might be:
>
> if any {foo, bar, baz} in foobar:
>
> and:
>
> if all {foo, bar, baz} in foobar:
>
> but I'm not sure how I feel about it...
Is this some new calling-like syntax, where `any {foo, bar, baz}` actually
calls something like `any.__braces__(foo, bar, baz)‘, and the all and any
builtins are changed to classes that implement that new dunder? If so, that
seems like a pretty major change for a small benefit. And it still wouldn’t
solve the problem, because whatever object it returns can’t override
__rcontains__ because there is no __rcontains__.
Or are you making any and all into contextual keywords—in most places they’re
just identifiers (which normally pick out the builtins at runtime) but in some
special context they’re instead syntax that means something special? If so,
what’s the context? It can’t be just “right after if”, because the functions
appear right after if all the time. Maybe “when followed directly by a
container display” could work without requiring unacceptable parser look ahead
(and without being ambiguous with existing valid syntax)? But that seems even
worse than most proposals for contextual keywords.
_______________________________________________
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/NEBYTVQTHNXOEZVUVYYI6Y364PGKAYLR/
Code of Conduct: http://python.org/psf/codeofconduct/
