On Sat, Aug 04, 2018 at 02:40:54PM -0400, Todd wrote:
On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
Boolean operators like the sort I am discussing have been a standard part of programming languages since forever. In fact, they are the basic operations on which modern microprocessors are built.
The fact that Python, strictly speaking, doesn't have them is extremely unusual for a programming language. [...] Sorry I wasn't clear, I didn't mean overloadable boolean operators are standard, but rather boolean operators in general. I was trying to point out that there is nothing domain-specific about boolean operators.
Right -- and Python has such common boolean operators. It isn't clear that there's much need for xor, nand, nor, etc. (There are a grand total of 16 distinct boolean operators which take two operands, but few of them are useful except under very specialised circumstances.) [I asked:]
Can you list some of these diverse and highly prominent use-cases?
I can think of two:
- elementwise boolean operators, such as in numpy;
- SQL-like DSL languages;
plus a third rather specialised and obscure use-case:
- implementing non-binary logical operators, for (e.g. ternary or fuzzy logic).
Also symbolic mathematics like in sympy. That is three.
I don't think symbolic mathematics is "highly prominent" (your words). I would consider it in the same category as fuzzy logic: specialised and unusual. To my mind, this basically means there are two important use-cases: - numpy and elementwise boolean operators; - SQL-like queries; and a couple of more specialised uses.
I think that before adding more ad hoc binary operators, we ought to consider the possibility of custom operators.
I am personally very strongly against custom operators. I just have visions of someone not liking how addition works for some particular class and deciding implementing a "＋" operator would be a great idea.
I have visions of someone not liking how boolean operators `or` and `and` work for some particular class and deciding that overridable boolean operators would be a great idea. Under my proposal, you couldn't invent new symbolic operators like ＋. Operators would be limited to legal identifiers, so people can do no worse than they can already do for method names, e.g. ugly names like "bOR" or "bAND". Given this proposal, your overridable boolean operators are instantly available, and using the proper names "or" and "and". There's no ambiguity, because the custom operators will always require a prefix (I suggested ~ but that won't work, perhaps ! or @ will work). And the benefit is that you don't have to come back next year with another PEP to introduce bNAND and bNOR operators. -- Steve