[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