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 -- http://mail.python.org/mailman/listinfo/python-list
