Some set operators

Discussion in 'Python' started by bearophileHUGS@lycos.com, Oct 15, 2005.

  1. Guest

    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_difference(), .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
     
    , Oct 15, 2005
    #1
    1. Advertising

  2. <> 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_difference(), .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.


    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.intersection(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 incompatibilities 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
     
    Alex Martelli, Oct 15, 2005
    #2
    1. Advertising

  3. 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_difference(), .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.


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

    </F>
     
    Fredrik Lundh, Oct 15, 2005
    #3
  4. 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++.

    Giovanni Bajo
     
    Giovanni Bajo, Oct 16, 2005
    #4
  5. Giovanni Bajo <> wrote:

    > 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++. 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
     
    Alex Martelli, Oct 16, 2005
    #5
  6. 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
     
    Giovanni Bajo, Oct 16, 2005
    #6
  7. Paddy Guest

    Hi Bearophile,
    Nah, you don't want to change 'em. I can remember 'em just fine :)
     
    Paddy, Oct 16, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bangalore
    Replies:
    4
    Views:
    1,262
    Fabio Fracassi
    Jul 27, 2005
  2. Giulio Veronesi

    set and operators

    Giulio Veronesi, Sep 19, 2005, in forum: C++
    Replies:
    6
    Views:
    337
    John Harrison
    Sep 19, 2005
  3. Giulio Veronesi

    set and operators

    Giulio Veronesi, Sep 19, 2005, in forum: C++
    Replies:
    0
    Views:
    304
    Giulio Veronesi
    Sep 19, 2005
  4. Set operators

    , Feb 2, 2006, in forum: C++
    Replies:
    16
    Views:
    621
    Gavin Deane
    Feb 3, 2006
  5. Replies:
    6
    Views:
    316
    Marco Mariani
    May 13, 2008
Loading...

Share This Page