On 2019-12-31 20:26, Andrew Barnert wrote:
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.
I was simply suggesting an alternative syntax to "any(foo, bar, baz)",
which already has a meaning. The other questions - to how it would work
- remain.
_______________________________________________
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/46MDD4DS2VPIQXGOXK4ZPHN3EU623F3N/
Code of Conduct: http://python.org/psf/codeofconduct/
