Some set operators

[Alex Martelli]

Giovanni Bajo <noway at sorry.com> wrote:

> Alex Martelli <aleax at mail.comcast.net> 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++.  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.

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.

I contend that having huge number of operators (and other built-ins)
goes against the grain of Python's simplicity, 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).

As for "serious plans", it's been a while since I checked PEP 3000, but
I don't think it addresses this issue one way or another -- yet.


Alex