[Python-Dev] More discussion on new infix operators

[Thomas Wouters]

On Sat, Jul 15, 2000 at 01:30:31PM -0700, Huaiyu Zhu wrote:

> 1.a) is unacceptable because infix operators improve readability
>       tremendously compared with prefix operators.  

Where's the usability study to prove that ? <wink> 

Seriously, though, claiming it is 'unacceptable' without providing
arguments ? Why is it unacceptable ? This solution has proven perfectly
acceptable for regular expressions, amongst other things. We have Perl
gurus, addicted to perl's builtin regexp syntax, join us all the time. And
you bet those perl people are addicted to short and confusing notations!

> 1.b) is unacceptable because it is too long and involves at least two method
>       calls and object initialization for each operation.

Not necessarily, it depends on your implementation. I would suggest
something as follows (probably highly inaccurate because I know didley squat
about matrices, but I'll give it a try):

class Matrix:
    "A container class to hold matrices."
    def __init__(self, <matrix data or sumtin'>):
        self.matrix = <usual matrix init code, I donno what.>
        self.elementwise = ElementwiseMatrix(self.matrix)

    def __mul__(self, val):
        return self.matrix.normalmultiply(val)

    <...>

class ElementwiseMatrix:
    "A container class to hold matrices, implementing elementwise operators."
    def __init__(self, matrix):
        self.matrix = matrix

    def __mul__(self, val):
        return self.matrix.elementwisemultiply(val)

    <...>


This will allow you to do something like this, given that 'a' and 'b' are
Matrices:

    a.elementwise * b.elementwise

to yield a new Matrix (or whatever would be most convenient.) With the
Cycle-GC patch, which is in 2.0, you can rewrite them a bit and add some
circular references (or you can do that now, if you don't mind having a
manual '.destroy()' method) so you can retrieve 'a' if you only have
'a.elementwise'. (Though I would suggest making the front-ends for the real
matrix as small as possible, not containing any data themselves, and just
create a new one whenever necessary. You just need to be sure not to use
'is' on the front-ends, then, but that's all.)

And like this, you can use 'ae = a.elementwise' and pass
'ae' around and operate on it. And this also works immediately with
augmented assignment, which might be in 2.0.

As for performance, two method calls and an object initialization aren't
really a problem, are they ? If you're looking for speed in many little
calculations, Python is the wrong language. If you're looking for speed in
large calculations, you won't notice this extra overhead. And in the
proposal above, the overhead is reduced anyway.

And like this, I'd say the whole thing is a lot more Pythonic! And it
clearly reflects the 'dual personality' of matrices.

> I hope, and I do believe personally, that it will acquire wide-spread usage
> once such basic facilities are provided, and will eventually be integrated
> into the core language.  It would be next to impossible to change operators
> at that moment.  Therefore I am most interested in hearing any thoughts on
> whether there exist any mortal danger for introducing the dot operators.
> For example, will it be confused with any planned new language features?

Well, I can (and will!) only speak for myself, but in my opinion, the
addition of the 'dot' operators would conflict more with the core of the
language than any specific feature. The entire philosophy of Python is to
keep it as clear and simple and easy to understand as possible. In that
light, even the use of the '%' symbol as the printf-operator is a mistake,
and I actually agree with that -- even though it's extremely useful. It will
be hard to explain to people who have no notion of strings, let alone
printf() ;-)

The 'dot' operators, though, remind me of the stories about ANSI C and how
Microsoft tried to convince the ANSI committee in charge of C to include
keywords specifically for the intel architecture. ('near', 'far', and two
others, I forget. They are (were?) necessary to deal with the way DOS (and
Windows ?) handles Intel's segmented memory model.) Even at that time, the
PC was the most used computer around, but the committee decided against
including these keywords. The PC might have have been the most used C
programming platform, but the committee argued that no single platform
should have that much impact on the programming language. (*)

I think the 'dot' operators are in the same position. It might bring a lot
of people to see the light if it had special matrix syntax, and that syntax
might even be applicable in a few other areas without causing too much
confusions. And I'd be happy for those people if they did see the light ;)
But it stays a single domain, and Python isn't just about drawing as many
people to Python as possible. At least, not in my humble opinion.

In short, I'm -0 on this idea. If the BDFL is indeed benificial in your
case, I won't put up a fight, but I wouldn't add it myself. 

But-then-I'm-only-+0-on-augmented-assignment-myself<0.3 wink>-ly y'rs,

(* This story comes from Peter v.d. Linden's Deep C Secrets. I'm sure Tim,
having sat on that committee under one alias or another, can tell this story
much more accurately ;-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!