[Python-checkins] python/dist/src/Misc NEWS,1.623,1.624

[tim_one@users.sourceforge.net]

Update of /cvsroot/python/python/dist/src/Misc
In directory sc8-pr-cvs1:/tmp/cvs-serv21358/python/Misc

Modified Files:
	NEWS 
Log Message:
date and datetime comparison:  when we don't know how to
compare against "the other" argument, we raise TypeError,
in order to prevent comparison from falling back to the
default (and worse than useless, in this case) comparison
by object address.

That's fine so far as it goes, but leaves no way for
another date/datetime object to make itself comparable
to our objects.  For example, it leaves Marc-Andre no way
to teach mxDateTime dates how to compare against Python
dates.

Discussion on Python-Dev raised a number of impractical
ideas, and the simple one implemented here:  when we don't
know how to compare against "the other" argument, we raise
TypeError *unless* the other object has a timetuple attr.
In that case, we return NotImplemented instead, and Python
will give the other object a shot at handling the
comparison then.

Note that comparisons of time and timedelta objects still
suffer the original problem, though.


Index: NEWS
===================================================================
RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v
retrieving revision 1.623
retrieving revision 1.624
diff -C2 -d -r1.623 -r1.624
*** NEWS	24 Jan 2003 22:15:53 -0000	1.623
--- NEWS	24 Jan 2003 22:36:31 -0000	1.624
***************
*** 101,104 ****
--- 101,112 ----
    also SF bug report <http://www.python.org/sf/660872>.
  
+   date and datetime comparison:  In order to prevent comparison from
+   falling back to the default compare-object-addresses strategy, these
+   raised TypeError whenever they didn't understand the other object type.
+   They still do, except when the other object has a "timetuple" attribute,
+   in which case they return NotImplemented now.  This gives other
+   datetime objects (e.g., mxDateTime) a chance to intercept the
+   comparison.
+ 
    The constructors building a datetime from a timestamp could raise
    ValueError if the platform C localtime()/gmtime() inserted "leap