>> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4