Some set operators

[bearophileHUGS]

Sometimes I suggest to add things to the language (like adding some set
methods to dicts), but I've seen that I tend to forget the meaning of
six set/frozenset operators:

s & t s &= t
s | t s |= t
s ^ t s ^= t

My suggestion is to remove them, and keep them only as explicit
non-operator versions (.symmetric_dif ference(), .update(),
..intersection_ update(), etc). But maybe now it's too much late to
remove them... Maybe someone gentle can explain me the advantage of
having/keeping them.

Thank you,
Bearophile

[Alex Martelli]

<be************ @lycos.com> wrote:

Sometimes I suggest to add things to the language (like adding some set
methods to dicts), but I've seen that I tend to forget the meaning of
six set/frozenset operators:

s & t s &= t
s | t s |= t
s ^ t s ^= t

My suggestion is to remove them, and keep them only as explicit
non-operator versions (.symmetric_dif ference(), .update(),
.intersection_u pdate(), etc). But maybe now it's too much late to
remove them... Maybe someone gentle can explain me the advantage of
having/keeping them.

Helen:~ alex$ python2.4 -mtimeit -s's1=s2=set()' 's1&s2'
1000000 loops, best of 3: 0.929 usec per loop

Helen:~ alex$ python2.4 -mtimeit -s's1=s2=set()' 's1.intersectio n(s2)'
1000000 loops, best of 3: 1.28 usec per loop

Besides avoiding the need for a name look-up, and thus extracting a tiny
speed-up of about 0.35 microseconds or so, I can't think of advantages
for the infix operator form (but then, I can't think of any advantages
for type *int* having the same operators, with bitwise-logic semantics,
rather than placing them only in some library module).

I still vaguely hope that in 3.0, where backwards incompatibiliti es can
be introduced, Python may shed some rarely used operators such as these
(for all types, of course). As long as the operators are there for
ints, it makes sense to have them apply to sets as well, of course.
Alex

[Fredrik Lundh]

be************@ lycos.com wrote:

Sometimes I suggest to add things to the language (like adding some set
methods to dicts), but I've seen that I tend to forget the meaning of
six set/frozenset operators:

s & t s &= t
s | t s |= t
s ^ t s ^= t

My suggestion is to remove them, and keep them only as explicit
non-operator versions (.symmetric_dif ference(), .update(),
.intersection_u pdate(), etc). But maybe now it's too much late to
remove them... Maybe someone gentle can explain me the advantage
of having/keeping them.

&, |, and ^ are Python's standard operators for AND, OR, and XOR. they
make as much sense for sets as they do for bitpatterns...

</F>

[Giovanni Bajo]

Alex Martelli <al***@mail.com cast.net> wrote:

I still vaguely hope that in 3.0, where backwards incompatibiliti es
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++.

Giovanni Bajo

[Alex Martelli]

Giovanni Bajo <no***@sorry.co m> wrote:

Alex Martelli <al***@mail.com cast.net> wrote:

I still vaguely hope that in 3.0, where backwards incompatibiliti es
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

[Giovanni Bajo]

Alex Martelli wrote:

I still vaguely hope that in 3.0, where backwards incompatibiliti es
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

[Paddy]

Hi Bearophile,
Nah, you don't want to change 'em. I can remember 'em just fine :-)