On Mon, 24 Nov 2008 10:42:41 +0000, Duncan Grisby wrote:
> Again, this is just an example. As I say, in the real application, the
> data has come from a dynamically-typed database. There's no easy way to
> coerce all the items to the same type, because the application doesn't
> know up-front what the data is going to look like. In some cases, it may
> be that all the data items are lists of strings. In other cases, all or
> most of the data items will be integers, for example.
...
> For my application, Python 3's comparison behaviour is a backwards step.
> You can argue all you like that the new behaviour is the "right" thing
> to do, and I'd be inclined to agree with you from a philosophical point
> of view, but the fact is that it _will_ cause problems for existing real
> code. The particularly ironic thing is that the database's dynamic
> typing is closely modelled on Python, including it's ability to
> gracefully handle mixed-type lists.
If I have understood you correctly, essentially you just need a variation
on the Null object pattern, one that accepts comparisons with any other
type. That's easy, because you don't have to worry about mutual
comparisons of multiple arbitrary types (sorting mixed strings and
numbers and null). All you need is something that sorts below everything
else: something just like None, except sortable.
Unfortunately you can't inherit from NoneType (that I know of...) but
inheriting from object should be good enough. If it isn't, you can use
delegation instead of inheritance. I leave that as an exercise for the
reader.
# not tested in Python 3
class SortableNone(object):
def __lt__(self, other):
return True
Null = SortableNone()
Now just use Null instead of None in your database.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
