Discussion: new operators for numerical computation

[Alex Martelli]

"Huaiyu Zhu" <hzhu at localhost.localdomain> wrote in message
news:slrn8o9s0a.sv.hzhu at localhost.localdomain...
> On Sat, 29 Jul 2000 14:07:17 +0200, Alex Martelli <alex at magenta.com>
wrote:
> [snip]
> >> FLAG = bitwise.or(FLAG1, FLAG2, FLAG3, FLAG4, FLAG5, FLAG6, FLAG7,
FLAG8)
> >
> >What an EXCELLENT idea.  shift left/right could also be packaged that
> >way (or, almost so; 'or' is a reserved words in Python...).

And I like your solution of finessing this via names bitor, bitand, etc.
This
also makes it sensible to 'from bitwise import *' in a module that does
heavy bitwise processing.

> >The 'bitwise' module could supply easily explicit bitfield-extraction
> >in place of the mask-and-shift idioms, too.

E.g., with your current prototype, bitget, bitset, and bitflip, for
single-bit
operations, and bitfieldget, bitfieldset, maybe bitfieldoperate for
multi-bit
fields operations.  You could see the purpose of this as 'marketing' -- an
attempt to make the new module more popular, by having it provide a
little useful extra prepackaged-functionality, that is often welcome in
program segments that do work with bitfields.


> >Oh well -- maybe a hint for Python 3000, when backwards compatibility
> >can be broken...!
>
> Why wait that long!  Here's a prototype.  If this becomes default, it
would
> be easier to replace the implementation in the future - with much less to
> break.

Maybe it could get into the Standard Distribution, and it would be trivial
to supply a C implementation of course (cBitfield perhaps?).  No way to
take away | & << >> ~ until Python 3000, of course, but, yes, surely when
3000's time comes life will be easier if bitwise is the popular way to do
things and the linenoise alternative an old/legacy/deprecated one:-).


Alex