[Python-Dev] datetime module enhancements

Steven Bethard steven.bethard at gmail.com
Sat Mar 10 21:01:40 CET 2007


On 3/10/07, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
> Steven Bethard <steven.bethard at gmail.com> wrote:
> > I still don't see why my more careful comparison would be bad for any
> > of your code. Could you give an example where it would be bad for all
> > the following to be False::
> >      date(2006, 1, 1) < datetime(2006, 1, 1, 0, 0, 0)
> >      date(2006, 1, 1) > datetime(2006, 1, 1, 0, 0, 0)
> >      date(2006, 1, 1) == datetime(2006, 1, 1, 0, 0, 0)
>
> You need me to explain why "a < b", "a > b" and "a == b" all being
> false simultaneously is bad!?

Yes.  One of the main reasons for having having rich comparisons
(__lt__, __eq__, etc.) is to be able to handle partial orderings like
the ones we're talking about here.

> What would "a != b" return?

True.  The intervals are not Simultaneous (equal).

> What would "cmp(a, b)" return?

According to the docs [1], "The return value is negative if x  < y,
zero if x == y and strictly positive if x > y." Which means that cmp()
is undefined in this case (and should probably raise an exception).
However, the current behavior is to return 1::

    >>> class C(object):
    ...     def __lt__(self, other):
    ...         return False
    ...     def __gt__(self, other):
    ...         return False
    ...     def __eq__(self, other):
    ...         return False
    ...
    >>> cmp(C(), C())
    1

Since I don't know too many folks that use cmp() instead of using <, >
or = directly, returning 1 is fine with me.  Anyone who has a problem
with that should take it up with the cmp() implementation.

[1] http://docs.python.org/lib/built-in-funcs.html#l2h-17

> > even though the following would be True::
> >      date(2006, 1, 1) < datetime(2006, 1, 2, 0, 0, 0)
> >      date(2006, 1, 1) > datetime(2005, 12, 31, 0, 0, 0)
>
> Actually, your suggestion would be much better than the current
> behaviour, for my uses

Good.  Well at least we're agreed on that part.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy


More information about the Python-Dev mailing list