Getting rid of bitwise operators in Python 3?

Stargaming stargaming at gmail.com
Sat Sep 22 01:06:42 EDT 2007


On Fri, 21 Sep 2007 23:44:00 -0400, Carl Banks wrote:

> Anyone with me here?  (I know the deadline for P3 PEPs has passed; this
> is just talk.)
> 
> Not many people are bit-fiddling these days.

Why did we invent the `binary literals`_ (0b101) then?
  
> One of the main uses of
> bit fields is flags, but that's not often done in Python because of
> keyword arguments and dicts, which are lot more versatile.  Another
> major use, talking to hardware, is not something oft done in Python
> either.

Talking to hardware, parsing files or network streams and all this stuff 
where you cannot rely on 8 bit encoding so well.

> It seems like this occasional usage wouldn't justify having built-in
> operators on its own.  And with the int/long unification, it makes a bit
> less sense to think of integers as a bit field.  Python has these
> operators because of its heritage, but Python continues to move away
> from the bad habits of its ancestors (integer division and so on), and I
> wonder if this isn't another one.

Heh, ``0b1 / 0b11`` would be 0.33333333333333331 then. Particularly 
funny. ;)

> Of course I'm not suggesting to get rid of bitwise operations
> altogether; just make them builtin functions: "x & 1" becomes
> "bitwise_and(x,1)" and so on.
>
> Is it worth it to make such a change?  It would remove a lot of
> operators (11 by my count), vastly simplifying syntax,  Which, IMHO, is
> no small thing.  New numerical types would have fewer operations to
> support.  And let's face it: unlike arithmetic opertaions, there's not a
> lot of different meanings for bit operations. And it would also, um,
> make new special characters available *cough*.

You're right about the simplification here perhaps. But nobody is forced 
to either learn or use (please, don't invert this argument justifying "we 
can implement any feature then -- don't use it if you don't like it!" ;)) 
them. But it's just a little bit sugar -- like, say, decorators -- and I 
like that.
 
> Obviously, how widespread their usage is would matter.  But keep in mind
> it would also be easy to convert the code automatically, because the
> Python parser could reliably find all bitwise operations reliably.  (The
> problem would be types that overloaded them to be something other than
> bitwise operations: I'm looking at you, set.  That could very well be a
> deal breaker.  I've never approved of things with completely different
> meanings being deliberately overloaded to have the same spelling; this
> is one reason why.)

A quick `google code search`_ failed but IMO those operators give you 
some freedom to make *your* classes more syntactical-sugar'ly. ``<<`` is 
used in PyParsing, as far as I know.

> If anyone says, "But that takes away an easy test for oddness (x&1)!",
> or, "But you can multiply powers of two using left shift!  Isn't that
> cool?", I'm not buying it.  Those are gimmicks.  Arithmetic operations
> should be done with arithmetic operators.  The bitwise operators make
> the code much less readable, especially to people unfamiliar with this
> usage.

Full acknowledgement! But in bit-wise environments, they can be 
particularly useful.

> the-above-pun-was-intended-ly yr's,
> 
> Carl Banks

.. _binary literals: http://www.python.org/dev/peps/pep-3127/
.. _google code search: http://www.google.com/codesearch?hl=en&lr=&q=lang%
3Apython+%3C%3C+%3E%3E+%7E+%26+%5C%7C+%5C%5E



More information about the Python-list mailing list