new bitwise module [was Re: Discussion: new operators ...]

[Alex Martelli]

"Christian Tanzer" <tanzer at swing.co.at> wrote in message
news:m13JrcJ-000wcEC at swing.co.at...
    [snip]
> Removing operators from a language is another topic, though.

Yep -- to wit...:

"""
A designer knows he has arrived at perfection, not when there is
no longer anything to add, but when there is no longer anything
to take away.
"""
(Antoine de Saint-Exupery).


For compatibility reasons, of course, nothing will ever be taken
away from Python-proper.  The curse of having a large installed
code-base, etc, etc.  But, by definition, Python 3000 will be _the_
chance to introduce backwards-incompatible changes to the
language.  Should those changes only consist of _additions_,
the way all languages, all systems, seem to tend to grow in time?

To those who think so, I suggest re-reading "Le Petit Prince" (I
am not sure the above quote is from Saint-Exupery's masterpiece
as opposed to other works such as "Vol de Nuit", actually -- I'm
taking it from one of Bentley's ACM columns of many years ago,
so I guess I'm due for another re-reading of "Prince" myself:-).


> If you started afresh on the design and implementation of a new
> language, there might well be compelling arguments to include matrix
> operators and exclude bitwise operators.

While Python 3000 is surely going to be nowhere as drastic as a
green-field new language design, it IS by definition going to have
such incompatibilities, isn't it?

I, being of sound mind and body, and a reasonably frequent user
of bit-twiddling, hereby declare that, except for compatibility,
bitwise operators strike me as one spot where there IS "something
to take away" from Python.  Named functions (better yet, maybe,
named-operators, if they were possible) appear preferable to me
for this task -- just as I prefer named-function for I/O to C++'s use
of << and >> (although I use those often, too), I would prefer a
named-function "format" to Python's % operator (which I also use
very often), etc, etc.  Further -- Python's strength is a core language
that is robust, minimalist, SMALL, accompanied by a very rich
standard-distribution library (plus of course many excellent
modules that are not standard-distributed).  If it's feasible (apart
from compatibility) to make the core language even smaller, why
not play to this Python's strength...?

So -- taking away nothing from anybody for now -- why not give
a try to a 'bitwise' module as an alternative.  It would need C-level
implementation for speed, of course, but it would be nice to play
around with the interface first, whence the Python implementation.

I gather from the tim-bot's comments that bitwise stands a comparable
chance to a snowball-in-hell's, so, OK, more's the pity.  But the
_idea_ still seems good to me, even if the BDFL and its Official
Channeler think otherwise.  Oh well.  I guess nothing at all will be
ever taken away from Python, and Python 3000 remain a myth...?


> But Python had bitwise operators for years (probably from day 1) and
> they are used in tons of code. Contrary to naive expectations, it is
> impossible to use a simple sed script to rewrite the existing code to
> use named functions instead of bitwise operators.

Isn't it truly fortunate, then, that we're not limited to simple sed
scripts,
but are privileged to be able to write powerful Python ones...?-)

> As to the benefits of bitwise operators: you are doing the case of
> matrix operators a disservice by disregarding other Python user's
> needs. You were not amused when others were unimpressed by the
> concerns of MatPy users.

Can't speak for anybody else, but I want to emphasize that my own
enthusiasm for the proposal had nothing to do with *disregarding
others' needs* -- I *AM* a reasonably frequent user of bit-twiddling
line noise... although, recently, C++'s std::bitset class has already
given me a chance of how NICE it is to be able to move a little bit
[pun intentional:-)] away from it.

I kept out from the MatPy thread because I have no real feeling
about how crucial the syntactic sugar is to that user base -- when I
did serious numerics, Fortran (and those new-fangled Linpack and
NAG things) were good enough for us, but that was a LITTLE BIT
of time ago, and I'd rather not yield too many hints to my age by
speaking much further of that:-).

But for bit-twiddling -- I'm current enough to have applicable
experience about how nice it is to get away from the linenoise (and
the redundant parentheses because nobody's ever 100% sure of
the priorities, and even if I am the next maintainer might not be:-) --
and the occasional fracas caused by a missing pair of parentheses
that turned out not to be redundant after all...:-).


> Don't-throw-stones-at-other-people's-glass-houses-ly y'rs,

If it's MY OWN vitreous edifice, can I lapidate it then...?-)


Alex