On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Nick Coghlan wrote: > >> Because this assertion is an assertion about the behaviour of >> comparisons that violates IEEE754, while the assertions I list are all >> assertions about the behaviour of containers that can be made true >> *regardless* of IEEE754 by checking identity explicitly. > > Aren't you making something of a circular argument here? > You're saying that non-reflexive comparisons are okay because > they don't interfere with certain critical invariants. But > you're defining those invariants as the ones that don't > happen to conflict with non-reflexive comparisons!
No, I'm taking the existence of non-reflexive comparisons as a given (despite agreeing with Meyer from a theoretical standpoint) because: 1. IEEE754 works that way 2. Even if float() is changed to not work that way, 3rd party types may still do so 3. Supporting rich comparisons makes it impossible for Python to enforce reflexivity at the language level (even if we wanted to) However, as I detailed in my reply to Antoine, the critical container invariants I cite *don't include* direct object-object comparisons. Instead, they merely describe how objects relate to containers, and how containers relate to each other, using only the two basic rules that objects retrieved from a container should be in that container and that two sets are equivalent if they are each a subset of the other. The question then becomes, how do we reconcile the container invariants with the existence of non-reflexive definitions of equality at the type level, and the answer is to officially adopt the approach already used in the standard container types: enforce reflexive equality at the container level, so that it doesn't matter that some types provide a non-reflexive version. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
