Sorry, the order was incorrect in that last message. It should be:
When x and y is written, if x has __booland__, then x.__booland__(y) is
returned. If not, then return x if x==False else if x==True, then if y has
y.__rbooland__(x), that is returned. If not, then return y.
On Monday, November 30, 2015 at 10:11:03 AM UTC-6, Henry Schreiner wrote:
>
> It seems to me there are two ideas being discussed. One is adding 2 new
> operators, something like && and ||, and providing them for some sort of
> "element wise" or other boolean context, and giving them a better order of
> evaluations than bitwise ops. This would have the advantage of being usable
> on the built in python lists/tuples if needed, but otherwise doesn't seem
> to solve all the issues above, including expressions like -1 < mat < 1,
> which work for python variables but not for things like Numpy arrays. (for
> example, selecting values from an array works like this: mat[(-1<mat) &
> (mat<1)] but not like this: mat[-1 < mat < 1] or this: mat[-1<mat &
> mat<1] ).
>
> The common "general purpose infix notation" pops up here, of course, but
> I'd consider it a variant of the first idea.
>
> The other idea is that overloads could be added to the existing and and or
> operators. This, I believe, would solve all the main problems, and would
> not add more to the language for a newcomer to learn. (In fact, most people
> could forget about the current bitwise and and or, since that's not what
> most people need, at least those using databases and Numpy). The downside
> is that the current and and or operators are short-circuiting, and adding
> a way to overload a short-circuiting operator is tricky/ugly/expensive
> (though the last one might not be that bad anymore). But, as I think Andrew
> was mentioning, what about a mixed solution? One that provides a
> non-short-circuiting overload, but the original short-circuiting behavior
> is default? It would look like this:
>
> Two new magic methods would be added, for now called __booland__ and
> __boolor__, along with __rbooland__ and __rboolor__.
>
>
>
> Evaluation would work like this, using and for an example:
> When x and y is written, if x has __booland__, then y.__booland__(y) is
> called. If it does not, then if y exists and has y.__rbooland__(x), that
> is called. If neither, then x and y is performed in a normal,
> short circuiting manner, calling bool(x) then calling bool(y) only if x
> == True. (The second line here might be the hard part due to the way
> short circuiting works)
>
>
>
> This would allow object that want custom and/or behavior to implement
> these magic functions. They would lose (explicit) short-circuiting, but
> they would gain custom behavior. Most of these special objects do not need
> or expect the short circuit behavior (Only if an array was all True or
> False would it even make sense in numpy , and this would allow
> expressions like -1 < mat < 1 to work as expected in Python. This would
> be easy to teach to newcomers, too, since only objects that have a definite
> True/False should short circuit, others have the special methods. The
> old behavior could be forced on overriding objects by wrapping them in
> bool().
>
>
> Would something like that be possible and better than PEP 335?
>
> PS:
> Either type of solution would also be useful for the Plumbum library, by
> the way, as it would be useful to add and-ing and or-ing to pipelines, but
> the bitwise operators have a different meaning for Plumbum. Due to the lazy
> evaluation of Plumbum, even the above solution (or any solution) would
> still allow short-circuiting in the pipeline.
>
>
>
