On 4/28/11 11:55 AM, Guido van Rossum wrote: > On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern<robert.kern at gmail.com> wrote: >> Smaller, certainly. But now it's a trilemma. :-) >> >> 1. Have just np.float64 and np.complex128 scalars follow the Python float >> semantics since they subclass Python float and complex, respectively. >> 2. Have all np.float* and np.complex* scalars follow the Python float >> semantics. >> 3. Keep the current IEEE-754 semantics for all float scalar types. > > *If* my proposal gets accepted, there will be a blanket rule that no > matter how exotic an type's __eq__ is defined, self.__eq__(self) > (i.e., __eq__ called with the same *object* argument) must return True > if the type's __eq__ is to be considered well-behaved; and Python > containers may assume (for the purpose of optimizing their own > comparison operations) that their elements have a well-behaved __eq__. *If* so, then we would then just have to decide between #2 and #3. With respect to this proposal, how does that interact with types that do not return bools for rich comparisons? For example, numpy arrays return bool arrays for comparisons. SQLAlchemy expressions return other SQLAlchemy expressions, etc. I realize that by being "not well-behaved" in this respect, we give up our rights to be proper elements in sortable, containment-checking containers. But in this and your followup message, you seem to be making a stronger statement that self.__eq__(self) not returning anything but True would be a bug in all contexts. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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