[Python-ideas] [Python-ideos] Dedicated overloadable boolean operators

[Sjoerd Job Postmus]

Regarding the short-circuiting `and` and `or`, I think there's a way we
can have our overloading-cake and only eat the pieces we need too.

Even though it might not be totally intuitive, it should be possible to
make the overloaded method get a 0-argument function instead of a value.

In that case, `a and b` would become `a.__land__(lambda: b)`. As far as
performance goes, there probably would have to be some special casing
that first checks if `a` has an overloaded `and`, and if not use the
default behaviour.

The default implementation:

    class object:
        def __land__(self, other_f):
    	    if not self:
    	        return self
             else:
                return other_f()

        def __lor__(self, other_f):
            if self:
                return self
            else:
                return other_f()

And for some python-expressions-to-AST nodeclass:

    class BaseExpression:
        def __land__(self, other_f):
            return AndExpression(self, other_f())
        def __lor__(self, other_f):
            return OrExpression(self, other_f())

Again, the fact that the second argument to `__land__`/`__or__` is a
function might be a bit confusing, but that's probably going to be the
only way to make short-circuiting work for an overloaded and/or without
going the route of lazy evaluation.

On Mon, Nov 23, 2015 at 04:13:42PM -0800, Guido van Rossum wrote:
> I honestly think the added confusion makes it a non-starter. It's also
> confusing that in other languages that have && and ||, they are
> shortcut operators, but the proposed operators here won't be. And the
> real question isn't "when to use & vs. &&", it's "when to use 'and'
> vs. &&".
> 
> On Mon, Nov 23, 2015 at 4:08 PM, Chris Angelico <rosuav at gmail.com> wrote:
> > On Tue, Nov 24, 2015 at 10:49 AM, Jelte Fennema <me at jeltef.nl> wrote:
> >> As for the PEP, I have no problem writing one if this is accepted as a
> >> useful addition. Also any suggestions and critiques are very welcome of
> >> course.
> >
> > I think it's reasonable, except for the potential confusion of having
> > *three* "and" operators. The one with the word is never going to
> > change - its semantics demand that it not be overridable. When should
> > you use & and when &&? Judging by how @ has gone, I think the answer
> > will be simple: "Always use &, unless the docs for some third-party
> > library say to use &&", in which case I think it should be okay.
> >
> > ChrisA
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/