Python 3.0 - is this true?

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Wed Nov 26 04:19:41 CET 2008


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



More information about the Python-list mailing list