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

Tue Nov 24 13:15:43 EST 2015

On Nov 24, 2015, at 02:10, Jelte Fennema <me at jeltef.nl> wrote:
> 
>> On 24 November 2015 at 06:35, Andrew Barnert via Python-ideas <python-ideas at python.org> wrote: 
>> -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.
> 
> This seems like an interesting idea, but I think it would be hard finding a notation that does not conflict with current operations.

The obvious notation is "a `spam` b", as used in Haskell and various other languages.

It doesn't conflict with current operations. It doesn't look like a pair of operators, but like a matched bracketing or quoting, which is exactly what we'd want. It has just about the right screen density (. can be easy to miss, while $ is so heavy that it makes the "in" in $in$ harder to read). It doesn't conflict with a different meaning elsewhere, like $(in), which can look like part of string template to a human reader.

Also, experience with those other languages shows that it works. In particular, in Haskell, I could always just define any new string of symbols to call spam on its operands, and with any precedence and associativity I want--but it's often much more readable to just use `spam` instead.

Its biggest problem is that Guido hates backticks, and is on record as promising that they will never be reused in Python now that they no longer mean repr. Since I don't think he'd accept the idea anyway (IIRC, last time it came up, he said it wasn't even worth writing a PEP to categorically dismiss), that makes this the perfect syntax for it. :)

More seriously, my point that infinity is a better number than 4 is more an argument against adding custom and, or, not , and in operators than an argument for adding custom arbitrary operators, which means the spelling isn't that important anyway. I don't think you're going to do much better than `and`, and I don't think that's good enough for Python.

> For the and/or almost any symbol would work, since they are keywords and the operators have no meaning on them,

No, because code has to be readable and parseable by humans, not just by compilers. Even if the compiler can tell that "spam.and.eggs" or "2.in.e" aren't using dots for member access or float purposes, that isn't clear to a human reader until you look at it carefully.

(Of course you can always use `and` or some other syntax that wouldn't be confusing even if and weren't a keyword, but at that point you're back to "no better than custom infixes".)

Also, bear in mind that what you're competing with is a.spam(b), so anything that looks too heavyweight or too weird, like a $(spam) b, isn't going to be much improvement except in very long expressions where closing the parens gets troublesome (which often aren't going to be readable anyway, and maybe it's not so terrible to encourage people to break them up and name subparts).

> but if any name can be used operations on variables will become unclear. So another symbol would probably have to be used that isn't used yet, like the $ symbol. Also, I think there are probably some other issues that I haven't thought of, since this would add a pretty big language feature.

Actually, last time I looked into it (around 3.4), it didn't have any other big issues or complex interactions with other features (and I don't think static typing, await, or any other changes will affect that, but I'd have to look more carefully). And it's pretty simple to implement, and pretty easy to describe. If you're interested, I may have written up a blog post, and if I didn't, I could write one now. (I think I also have a hack that implements it with a retokenizing import hook, if you want to play with it.)

While we're at it, every time custom infix operators come up, someone points out that you can already fake it pretty well. For example, "a &And& b" just needs a global named "And" whose __rand__(self, a) returns an object whose __and__(self, b) does what you want. And this allows you to use whatever precedence you want by picking the surrounding operators (much like Swift's custom infix operators get their precedence from the first symbol in the name), and lets you implement operator sectioning (you can make __rand__(self, a).__call__ the same as its __and__, and then you can pass around "a &And" as a partial function), and so on. There are a few glitches, but it works well with the kind of code you'd write with an ORM. And again, this is just as true for a proposal to add four custom operators as for a proposal to add a general feature. So, you have to think about why sqlanywhere, numpy, etc. have decided not to use this trick so far, when it's been well known since around the days of Python 2.4, and why they'd be better off with custom operators that don't look that different from the fake ones.

> PS. I didn't include the dollar convention in my last options list for the new and operator, but it is ofcourse also a possibility: $and$, or maybe $and. 
> 
>> On 24 November 2015 at 06:35, Andrew Barnert via Python-ideas <python-ideas at python.org> wrote:
>> (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".
>> _______________________________________________
>> 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/
>> 
>> --
>> 
>> ---
>> You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/5bEW_wwNJcM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151124/42064fe2/attachment-0001.html>