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 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.
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.
PPS: Hopefully I’m not double posting, apparently the google group and the mailing list are separate subscriptions.