[Python-checkins] python/nondist/sandbox/datetime doc.txt,1.35,1.36

2002年12月09日 09:42:04 -0800

Update of /cvsroot/python/python/nondist/sandbox/datetime
In directory sc8-pr-cvs1:/tmp/cvs-serv18364
Modified Files:
	doc.txt 
Log Message:
Updated OPEN/TODO list after triage review w/ Guido, and moved some to a
new CLOSED list (there were closed w/o action).
Index: doc.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/sandbox/datetime/doc.txt,v
retrieving revision 1.35
retrieving revision 1.36
diff -C2 -d -r1.35 -r1.36
*** doc.txt	9 Dec 2002 16:37:17 -0000	1.35
--- doc.txt	9 Dec 2002 17:42:02 -0000	1.36
***************
*** 5,13 ****
 - timetz needs a C implementation.

- - Behavior in Boolean contexts. Currently time(0) and timedelta(0) act
- as false, everything else acts true. Is this desired? timedelta(0)
- seems reasonable since it's very number-like, but time(0) acting false
- bothers me (midnight isn't especially more zero-like than noon).
- 
 - What should str() do? It generally acts like a synonym for isoformat()
 now. But
--- 5,8 ----
***************
*** 20,23 ****
--- 15,21 ----
 implementation has (overridden) "pretty __str__" according to one
 person's idea of "pretty", for a couple types. Rat hole.
+ Guido sez: chop ".000000" when microseconds are 0, and that's it.
+ Tim sez: and having a fixed-size string when they are will make
+ life easier for people implementing their own ideas of "pretty".

 - The METH_CLASS bug affects about a dozen functions here. They'll need
***************
*** 25,36 ****
 be fixed.

- - pickles still "feel too big".
- 
 - Subclass relationships. Currently datetime is a subclass of date.
 I like this in practice, and think it's theoretically sound too.
 Should this be blessed? I expect the same questions to pop up for
 timetz wrt time, and datetimetz wrt datetime.
! 
! - The type objects aren't exposed, due to headaches with DLL/.so.

 - LaTeXize the docs.
--- 23,32 ----
 be fixed.

 - Subclass relationships. Currently datetime is a subclass of date.
 I like this in practice, and think it's theoretically sound too.
 Should this be blessed? I expect the same questions to pop up for
 timetz wrt time, and datetimetz wrt datetime.
! Guido sez subclassing is fine. Add docs about the subclass
! relationships.

 - LaTeXize the docs.
***************
*** 38,45 ****
 - Move from sandbox to mainline.

 - Every function involving a timestamp inherits platform C limitations
 on year range, on resolution, and on precision. If we were to invent
 our own timestamp format, an IEEE double doesn't have enough bits to
! cover 9999 years to microsecond resolution.

--- 34,56 ----
 - Move from sandbox to mainline.

+ 
+ CLOSED
+ ======
+ - pickles still "feel too big". But this is a general issue w/ new-style
+ classes.
+ 
+ - The type objects aren't exposed at the C level, due to headaches with
+ DLL/.so. We're going to ignore this; if you need to construct, e.g.,
+ a datetime object from C, the constructors can still be gotten via
+ importing the datetime module and calling the appropriate method.
+ 
 - Every function involving a timestamp inherits platform C limitations
 on year range, on resolution, and on precision. If we were to invent
 our own timestamp format, an IEEE double doesn't have enough bits to
! cover 9999 years to microsecond resolution. Tough. The only methods
! in this module that *produce* timestamps (as opposed to consuming them)
! are in datetimetz, and people will have to live with that limitation.
! Other methods are timestamp consumers, and suffer platform limitations
! no matter what we do here.

***************
*** 657,661 ****
 PyDateTime_GET_DAY(o)

! Ror datetime and date instances:
 PyDateTime_DATE_GET_HOUR(o)
 PyDateTime_DATE_GET_MINUTE(o)
--- 668,672 ----
 PyDateTime_GET_DAY(o)

! For datetime and date instances:
 PyDateTime_DATE_GET_HOUR(o)
 PyDateTime_DATE_GET_MINUTE(o)