Greg Ewing wrote: [SNIP] Just a couple of quick comments on the motivation: > Motivation > ========== > > There are many applications in which it is natural to provide custom > meanings for Python operators, and in some of these, having boolean > operators excluded from those able to be customised can be > inconvenient. Examples include: > > 1. Numeric/Numarray, in which almost all the operators are defined on > arrays so as to perform the appropriate operation between > corresponding elements, and return an array of the results. For > consistency, one would expect a boolean operation between two > arrays to return an array of booleans, but this is not currently > possible. > > There is a precedent for an extension of this kind: comparison > operators were originally restricted to returning boolean results, > and rich comparisons were added so that comparisons of Numeric > arrays could return arrays of booleans. For Numeric/Numarray, I think and1/or1 would be unnecessary. If that were true in general it would simplify the proposal signifigantly: and2/or2 could be renamed to and/or and and1/or1 could be dropped. > 2. A symbolic algebra system, in which a Python expression is > evaluated in an environment which results in it constructing a tree > of objects corresponding to the structure of the expression. > > 3. A relational database interface, in which a Python expression is > used to construct an SQL query. I would be interested in seeing use cases for either or both of these last two examples that show how and1/or1 are useful. Regards, -tim
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