[Python-Dev] PEP 207 -- Rich Comparisons

[Paul Barrett]

>> This example also makes me think that the proposals for new operators
>> (ie.  PEP 211 and 225) are a good idea.  The discussion of rich
>> comparisons in 1998 also lends some support to this.  I can see many
>> uses for two types of comparison operators (as well as the proposed
>> matrix-type operators), one set for poor or boolean comparisons and
>> one for rich or non-boolean comparisons.  For example, numeric arrays
>> can define both.  Rich comparison operators would return an array of
>> boolean values, while poor comparison operators return a boolean value
>> by performing an implied 'and.reduce' operation.  These operators
>> provide clarity and conciseness, without much change to current Python 
>> behavior.
>
> 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.

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

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.

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,
Paul

-- 
Dr. Paul Barrett       Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Group
FAX:   410-338-4767    Baltimore, MD 21218