On Friday, November 6, 2015 at 2:58:24 AM UTC-8, Eric Gourgoulhon wrote: > > > However, your example with NAN in the reply to Simon shows that dictionary > lookup shortcuts equality testing on identical keys. If I understand > correctly, this means that even if we had a slow __eq__ for charts, as soon > as we write > point._coordinates[X] with the chart X that is the same object as the one > used to create the entry in the dictionary point._coordinates, then we > would have fast access to the coordinates? Could this depend on the Python > version/implementation? (i.e. can we rely on this for the future?). If yes, > we may even abandon EqualityById for charts. > I'm pretty sure that this is an implementation detail of CPython. Also, the dict in CPython is designed to do very few equality tests if you look up a key with a hash value that only occurs once or not at all for the keys present in the dictionary, but the number is not zero.
Furthermore, if X and Y happen to be non-identical but "equal" charts, would you want points._coordinates[X] be identical to points_coordinates[Y] ? Would that ever be useful? EqualityById is easy and cheap to have. It basically restores the default equality- and hashing properties of Python's objects. I don't think it's something you should particularly avoid having. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
