[Python-Dev] PEP 207 -- Rich Comparisons

[Guido van Rossum]

> > Maybe.  That can still be decided later.  Right now, adding operators
> > is not on the table for 2.1 (if only because there are two conflicting
> > PEPs); adding rich comparisons *is* on the table because it doesn't
> > change the parser (and because the rich comparisons idea was already
> > pretty much worked out two years ago).
> 
> Yes, it was worked out previously _assuming_ rich comparisons do not
> use any new operators.  
> 
> But let's stop for a moment and contemplate adding rich comparisons 
> along with new comparison operators.  What do we gain?
> 
> 1. The current boolean operator behavior does not have to change, and
>    hence will be backward compatible.

What incompatibility do you see in the current proposal?

> 2. It eliminates the need to decide whether or not rich comparisons
>    takes precedence over boolean comparisons.

Only if you want different semantics -- that's only an issue for NumPy.

> 3. The new operators add additional behavior without directly impacting 
>    current behavior and the use of them is unambigous, at least in
>    relation to current Python behavior.  You know by the operator what 
>    type of comparison will be returned.  This should appease Jim
>    Fulton, based on his arguments in 1998 about comparison operators
>    always returning a boolean value.

As you know, I'm now pretty close to Jim. :-)  He seemed pretty mellow
about this now.

> 4. Compound objects, such as lists, could implement both rich
>    and boolean comparisons.  The boolean comparison would remain as
>    is, while the rich comparison would return a list of boolean
>    values.  Current behavior doesn't change; just a new feature, which
>    you may or may not choose to use, is added.
> 
> If we go one step further and add the matrix-style operators along
> with the comparison operators, we can provide a consistent user
> interface to array/complex operations without changing current Python
> behavior.  If a user has no need for these new operators, he doesn't
> have to use them or even know about them.  All we've done is made
> Python richer, but I believe with making it more complex.  For
> example, all element-wise operations could have a ':' appended to
> them, e.g. '+:', '<:', etc.; and will define element-wise addition,
> element-wise less-than, etc.  The traditional '*', '/', etc. operators
> can then be used for matrix operations, which will appease the Matlab
> people.
> 
> Therefore, I don't think rich comparisons and matrix-type operators
> should be considered separable.  I really think you should consider
> this suggestion.  It appeases many groups while providing a consistent 
> and clear user interface, while greatly impacting current Python
> behavior. 
> 
> Always-causing-havoc-at-the-last-moment-ly Yours,

I think you misunderstand.  Rich comparisons are mostly about allowing
the separate overloading of <, <=, ==, !=, >, and >=.  This is useful
in its own light.

If you don't want to use this overloading facility for elementwise
comparisons in NumPy, that's fine with me.  Nobody says you have to --
it's just that you *could*.

Red my lips: there won't be *any* new operators in 2.1.

There will a better way to overload the existing Boolean operators,
and they will be able to return non-Boolean results.  That's useful in
other situations besides NumPy.

Feel free to lobby for elementwise operators -- but based on the
discussion about this subject so far, I don't give it much of a chance
even past Python 2.1.  They would add a lot of baggage to the language
(e.g. the table of operators in all Python books would be about twice
as long) and by far the most users don't care about them.  (Read the
intro to 211 for some of the concerns -- this PEP tries to make the
addition palatable by adding exactly *one* new operator.)

--Guido van Rossum (home page: http://www.python.org/~guido/)