Some set operators

[Giovanni Bajo]

Alex Martelli wrote:

>>> I still vaguely hope that in 3.0, where backwards incompatibilities
>>> can be introduced, Python may shed some rarely used operators such
>>> as
>>> these (for all types, of course).
>>
>> I hope there is no serious plan to drop them. There is nothing wrong
>> in having such operators, and I wouldn't flag bit operations as
>> "rarely used". They are very common when calling C-based API and
>> other stuff. I know I use them very often. They have a clear and
>> well-understood meaning, as they appear identical in other
>> languages, including the widely-spread C and C++.
>
> Well, C and C++ don't have unbounded-length integers, nor built-in
> sets, so the equivalence is slightly iffy; and the precedence table of
> operators in Python is not identical to that in C/C++.

The equivalence was trying to make a point about the fact that bitwise
operators are not an uncommon and obscure operator like GCC's "<?=" (so-called
"update minimum") operator. "&" reads as "and" to English readers, "|" reads as
"or" in regular expression. It's not something weird we have come up with just
by sticking a couple of symbols together.

> As for
> frequency
> of use, that's easily measured: take a few big chunks of open-source
> Python code, starting with the standard library (which does a lot of
> "calling C-based API and other stuff") and widespread applications
> such as mailman and spambayes, and see what gives.

I grepped in a Python application of mine (around 20k lines), and I found about
350 occurrences of ^, | and &, for either integers or builtin sets.

> But the crux of our disagreement lies with your assertion that there's
> nothing wrong in having mind-boggling varieties and numbers of
> operators, presumably based on the fact that C/C++ has almost as many.

When exactly did I assert this? I am just saying that an infix operator form
for bitwise or, and, xor is very useful. And once we have them for integers,
using them for sets is elegant and clear. Notice also that a keyword-based
alternative like "bitand", "bitor", "bitxor" would serve well as a replacement
for the operators for integers, but it would make them almost useless for sets.

> I contend that having huge number of operators (and other built-ins)
> goes against the grain of Python's simplicity,

We agree on this.

> makes Python
> substantially harder to teach, and presents no substantial advantages
> when compared to the alternative of placing that functionality in a
> built-in module (possibly together with other useful bit-oriented
> functionality, such as counts of ones/zeros, location of first/last
> one/zero bit, formatting into binary, octal and hexadecimal, etc).

Such a module would be very useful, but I believe it's orthogonal to having an
infix notation for common operations. We have a string module (and string
methods), but we still have a couple of operators for strings like "+".
-- 
Giovanni Bajo