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

[Henry Schreiner]

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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151130/3a22d0ec/attachment-0001.html>