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

Andrew Barnert abarnert at yahoo.com
Tue Nov 24 00:35:52 EST 2015


(Top-posting because this is really a reply to a combination of three earlier posts, not to Greg Ewing's post, except at the very end.)

-1 on "&&" and "||". To anyone familiar with C and friends, it seems like they ought to be like C (short-circuiting, and more generally the same thing we already spell "and" and "or"); to anyone else, it would make no sense for them to have different precedence than "&" and "|".

-0.5 on ".and." and ".or." for multiple reasons, most of which apply just as well to anything similar:

* That looks like a general custom-infix syntax. Anyone coming to Python (including Python 2 users) will expect that they can just as easily define ".spam." (and then be disappointed that they can't...), or will be worried that 3.7 will add a bunch of new dot operators they'll have to learn. Not a _huge_ negative, but already enough to turn me off the idea.

* What would you call the dunder methods (and operator module functions), and how would you deal with the fact that any novice/transplant is going to assume "__and__" means ".and." rather than "&"?

* Operators starting with "." are ambiguous with float literals and/or attribute access ("spam.and.eggs" looks like a member of a member of spam), at least to humans, if not to the parser.

* Operators starting and/or ending with "." are hard to talk about because of natural-language punctuation (and even harder on a mobile keyboard, or an overly clever text editor or word processor).

-0 on actually adding a general custom-infix syntax, come to think of it. Any solution to the problems above should work just as well here. And it means that in the future, libraries don't have to cram things into inappropriate symbols or be stuck with prefix or dot-method notation. And I don't think it would be any harder to learn than a few special cases. And I think ".between." would be just as useful in an ORM as ".in.". More generally, the whole point of "@" was that everyone agreed that it was the only new operator anyone would need (except maybe "@@") for a decade or two; if that's not true, infinity is a better number than 4.

+1 on the idea if someone can come up with a good spelling that avoids all the above problems and reads as naturally as "@".

> On Nov 23, 2015, at 20:55, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> Bruce Leban wrote:
>> If this idea were to fly, a better name would be something that doesn't have that problem, e.g., .and. .or. .not.
> 
> Dots are a bit on the ugly side.
> 
> Some other possibilities:
> 
> AND, OR, NOT
> 
> And, Or, Not
> 
> en, of, nlet

Is that last one supposed to be "niet"? When I try "nlet", Google assumes it's a typo for "net", which I guess could be a unary boolean identity operator, but I don't think we need that. :)

Anyway, that pattern is a bit hard to extend to an overloadable "in" operator, because Dutch for "in" is "in".


More information about the Python-ideas mailing list