On Thu, Jul 19, 2018, 5:12 AM Chris Angelico
On Thu, Jul 19, 2018 at 4:06 PM, Greg Ewing
wrote: There's a very long tradition of using the symbol "+" to represent addition, so it's something most people are familiar with. There's no such tradition for the new operators being proposed.
Okay. What about bitwise operators, then? They don't have centuries of mathematical backing to support them, yet it isn't considered "unpythonic" to have &|^~ peppering our code.
I have quite literally NEVER seem Python code with much use of the bitwise operators. I guess the closest I've come is in some NumPy and Pandas code where filters cannot use plain 'and' and ' or' but every student would find it more intuitive if they could. E.g. myDf[(myDf.field1 > 4) & (myDf.field2 < 2)] Everyone still gets tripped up by the need for those parentheses because of operator precedence. But this already yells or "special domain" rather than "plain Python". Indeed, it not uncommon or unreasonable to recommend using np.bitwise_and() to avoid those confusing operators. In the case where bitwise masking is used in its C manner, the code screams special domain even more loudly. It definitely feels strongly unPythonic, but it's often a reasonable compromise for dealing with just a little bit of binary data without having to write a C extension. I would ALWAYS want the code that used bitwise operators wrapped in a separate function that most users and developers didn't need to look at, but rather they'd call a more Pythonic API for the overall operation. A huge difference is that bitwise operators do something you simply cannot do other ways in Python at all. None-aware operators *at best* allow you to write something with an existing straightforward approach using a couple fewer lines. I think the result is ALWAYS less clear to read. Code golf is an anti-goal in Python.