[Python-checkins] python/dist/src/Misc NEWS,1.645,1.646

tim_one@users.sourceforge.net tim_one@users.sourceforge.net
Fri, 07 Feb 2003 14:50:30 -0800


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

Modified Files:
	NEWS 
Log Message:
Comparison for timedelta, time, date and datetime objects:  __eq__ and
__ne__ no longer complain if they don't know how to compare to the other
thing.  If no meaningful way to compare is known, saying "not equal" is
sensible.  This allows things like

    if adatetime in some_sequence:
and
    somedict[adatetime] = whatever

to work as expected even if some_sequence contains non-datetime objects,
or somedict non-datetime keys, because they only call __eq__.

It still complains (raises TypeError) for mixed-type comparisons in
contexts that require a total ordering, such as list.sort(), use as a
key in a BTree-based data structure, and cmp().


Index: NEWS
===================================================================
RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v
retrieving revision 1.645
retrieving revision 1.646
diff -C2 -d -r1.645 -r1.646
*** NEWS	6 Feb 2003 23:10:45 -0000	1.645
--- NEWS	7 Feb 2003 22:50:27 -0000	1.646
***************
*** 141,144 ****
--- 141,159 ----
    comparison.
  
+   date, time, datetime and timedelta comparison:  When the exception
+   for mixed-type comparisons in the last paragraph doesn't apply, if
+   the comparison is == then False is returned, and if the comparison is
+   != then True is returned.  Because dict lookup and the "in" operator
+   only invoke __eq__, this allows, for example,
+ 
+       if some_datetime in some_sequence:
+   and
+       some_dict[some_timedelta] = whatever
+ 
+   to work as expected, without raising TypeError just because the
+   sequence is heterogeneous, or the dict has mixed-type keys.  [This
+   seems like a good idea to implement for all mixed-type comparisons
+   that don't want to allow falling back to address comparison.]
+ 
    The constructors building a datetime from a timestamp could raise
    ValueError if the platform C localtime()/gmtime() inserted "leap
***************
*** 272,276 ****
  - There are new dialogs EasyDialogs.AskFileForOpen, AskFileForSave
    and AskFolder. The old macfs.StandardGetFile and friends are deprecated.
!   
  - Most of the standard library now uses pathnames or FSRefs in preference
    of FSSpecs, and use the underlying Carbon.File and Carbon.Folder modules
--- 287,291 ----
  - There are new dialogs EasyDialogs.AskFileForOpen, AskFileForSave
    and AskFolder. The old macfs.StandardGetFile and friends are deprecated.
! 
  - Most of the standard library now uses pathnames or FSRefs in preference
    of FSSpecs, and use the underlying Carbon.File and Carbon.Folder modules