[PEP draft 2] Adding new math operators

Bernhard Herzog herzog at online.de
Wed Aug 9 17:59:11 EDT 2000


hzhu at localhost.localdomain (Huaiyu Zhu) writes:

> On 09 Aug 2000 01:01:21 +0200, Bernhard Herzog <herzog at online.de> wrote:
> >hzhu at localhost.localdomain (Huaiyu Zhu) writes:
> >
> >> The symbol ~ is already used in Python as the unary "bitwise not" operator.
> >> Currently it is not allowed for binary operators, so using it as a prefix to
> >> binary operators will not create incompatibility.
> >
> >There are a couple of cases where this is incompatible. The expression
> >~-1 is valid Python today and is parsed as the three tokens ~ - 1. With
> >the proposed new operators, ~- will be recognized as one token so the
> >expression will parse as the two tokens ~- 1 which is invalid because ~-
> >is a binary operator. The other case is ~+1.
> 
> From what I understand, the parser can distinguish unary and binary
> operators, so that ~-1 will not be parsed as ~- 1, because it's not
> following an operand.   

I think I should have been clearer. The tokenizer doesn't know about the
context, so whenever it sees ~- in its input character stream it
recognizes the new ~- operator, unless that happens to be inside of a
string or a comment, of course. 

The parser, OTOH, which just fetches tokens one by one from the
tokenizer, can distinguish between unary and binary operators and it
will see ~- at the beginning of an expression and complain because it
can only be used as a binary operator.

In the part you didn't quote:

  You could probably work around it by also allowing ~+ and ~- to be
  used as unary operators, but that seems awkward.

I was trying to say that to work around this, you have to extend the
grammar and compile the unary operators ~+ and ~- as if they mean ~ +
and ~ - respectively.

Since it can be worked around, this collision of ~- and ~ - is not a
showstopper, but the workaround seems ugly to me.

> >>    - The bitwise operators assign special syntactical and semantical
> >>      structures to operations that are not as fundamental as math.  
> >
> >That's a pretty bold statement to make about a general purpose
> >programming language. One could easily argue that bitwise operation are
> >much more fundamental than matrix operations on a computer. Even though
> >Python is much higher level than e.g. Assembler or C, there are lots of
> >uses for these operations, like e.g. reading and writing binary files or
> >determining the status of mouse buttons in a GUI (in tkinter you have to
> >check the individual bits of the state attribute of the event)
> 
> Well, conceptually, two sets of operators are equally fundamental: the
> arithmetic type operators + - * / and the lattice type operators (and) (or)
> (not) (xor), etc.  Both of them have two versions, objectwise and
> elementwise. The bitwise operators are elementwise lattice operators when
> each bit in an integer is regarded as an element.

Well, I kind of like this orthogonality of objectwise and elementwise
operations and the way it extends to integers and bitwise operations. My
main gripe with the PEP was that it claims that bitwise operations are
less fundamental than 'math' which in context probably meant
matrix-operations or, broader, arithmetic.

> Elementwise operators in the form of ~and ~or ~not ~xor is as fundamental as
> the elementwise arithmetic operators in the form of ~+ ~- ~* ~/.  However,
> the specific restriction of the former to bitwise operation on integers is
> not as fundamental.

This is getting a bit hairsplitting, but the statement in the PEP I
quoted above talked about operations, not operators, which are very
different things. Some operations such as arithmetic is very fundamental
and important, so having special operator symbols for that is very
convenient. Other operations are less fundamental or less often used and
whether Python should have operators for those is less obvious and, of
course, it's what this PEP is all about.

> If we view Python as a high level OO lanauge, we should be more concerned
> with the potential of operator overloading on arbitary objects than on the
> particular builtin types.  The distinction between elementwise and
> objectwise operations is not limited to numerical computation.

True, it isn't limited to numerical computation, but how easily can it
be extended to other types of objects? And how intuitive or obvious are
the new operators? And, is this distinction fundamental and important
enough to enough python users to warrant the introduction of a
relatively large range of new operators? 

Ok, now I have to go an reread the PEP to find out if and how these
points are being addressed. :-)

-- 
Bernhard Herzog   | Sketch, a drawing program for Unix
herzog at online.de  | http://sketch.sourceforge.net/



More information about the Python-list mailing list