Josiah Carlson wrote: > Jim Fulton <[EMAIL PROTECTED]> wrote: >> Jim Jewett wrote: >>> PEP 3000 now suggests that dropping default comparison has become more >>> than an idle what-if. >>> >>> Unfortunately, one very common use case of comparisons is to get a >>> canonical order. If the order is sensible, all the better, but that >>> is not strictly required. One of Python's selling points (especially >>> compared to Java) is that getting a canonical order "just works", even >>> if the objects being sorted are not carefully homogenized by hand. >>> Python itself relies on this when comparing same-length dictionaries. >>> >>> There are times when a specific comparison doesn't make sense (date vs >>> a datetime that it includes), but these are corner cases best handled >>> by the specific class that understands the specific requirements -- >>> classes that already have to override the comparison operators anyhow. >>> >>> Even the recently posted "get rid of default comparisons" use case is >>> really just an argument to make the canonical ordering work better. >>> The problem Jim Fulton describes is that the (current default) >>> canonical order will change if objects are saved to a database and >>> then imported to a different session. Removing default comparisons >>> wouldn't really help much; the errors would (sometimes) show up at >>> saving instead of (maybe) at loading, but the solution would still be >>> to handcode a default comparison for every single class individually. >> I think you need to do a much better job of defining canonical ordering. >> >> You've given two properties: >> >> - It need not make sense. :) >> >> - It must be consistent accross sessions >> >> Does this also mean accross different versions of Python? >> >> How about different operating systems and hardware? >> >> If I create and pickle a BTree with a bunch of object keys >> and reload that pickle in a different session, with a >> later version of Python on a different OS and Hardware >> architecture, will the keys still have the same order? >> >> I consider (obviously) this second property to be crucial. >> >> Do you have any proposal for how to achieve these properties? > > New superclasses for all built-in types (except for string and unicode, > which already subclass from basestring). > > int, float, complex (long) : subclass from basenumber > tuple, list, set : subclass from basesequence > dict : subclass from basemapping
set should be under basemapping. > The idea is that each of the above classes define a group in which items > are comparable. If you end up in a situation in which the base classes > of the compared object differ (and hence are not comparable directly by > value), you compare their base class name. Because their base classes > differ, you always get a reliable differentiation between groups. Python already uses this "trick" based on the type name. If that still doesn't help, id(object) is used which is what JimF is criticizing (I presume). > What about comparisons between user-defined classes (classic or subclass > of object)? Presumably if a user wanted something to be compared > against integers, floats, or complex, the user would subclass from > basenumber, etc. ... and get all kinds of weird side-effects. A user probably doesn't want these :-) > If the user only wanted their objects to compare > against objects of its own type, they compose their own __cmp__ or > related methods on their class, and they get this behavior 'for free'. > > The only thing necessary for canonical ordering persistancy is that the > content of an object define its behavior in comparison operators, and > that pickle knows how to save and restore this content reliably. Actually, the only thing necessary for *persisting* order is making sure that the persistence logic maintains order across pickling. Note that this is a completely different requirement than making sure that the outcome of list.sort() is the same across platforms and sessions. > Note that one can remove the superclass requirement with a smart cmp() > builtin to automatically choose the comparable group. > > > This is not perfect, but it is an idea, and it would allow a reliable > canonical ordering. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 20 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________ 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