On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern <robert.k...@gmail.com> wrote: > On 4/28/11 11:55 AM, Guido van Rossum wrote: > >> On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern<robert.k...@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.
Sorry, we'll have to make an exception for those of course. This will somewhat complicate the interpretation of well-behaved, because those are *not* well-behaved as far as containers go (both dict key lookup and list membership are affected) but it is not a bug -- however it is a bug to put these in containers and then use container comparisons on the container. -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com