On 5/25/02 2:56 PM, "Ian Bicking" <ianb@...> wrote:
> On Sat, 2002-05-25 at 11:44, Mike Orr wrote:
>> On Sat, May 25, 2002 at 05:07:13AM -0700, Steve Freitas wrote:
>>>> I am pretty sure that the mxDateTime isn't "stock" in any of the python
>> It's definitely not part of Python's standard library. Python has an
>> extremely high standard for what is allowed into the standard library,
>> to avoid clutter that looks good at the time but then gets depreciated
>> later. It has to be (1) obviously THE best solution, (2) something the
>> Python team is willing to take over maintenance of (except the new xml
>> package, which is maintained by a third party). Of course it's not
>> perfect. String, regex, ftplib and xmllib got into the standard library
>> even though much better alternatives were found later.
> mxDateTime would belong in the standard library by this convention. In
> fact, it's part of the DB2.0 standard (optional, but database adapters
> are supposed to use mxDateTime if it available, not home-grown classes
> or things based on the time module). mxDateTime is, IMHO, the only
> reasonable way to deal with dates in Python -- other third-party classes
> don't offer significant benefits, and are not guaranteed to be
> maintained and updated. The time module just sucks horribly -- tuple
> data structures are crazy.
> I don't know if the author wishes to keep it separate, or what. It
> wouldn't make sense to distribute mxDateTime with Webware, as it is
> mostly written in C, and that makes it much more complicated to deal
> with. A couple Python modules are easy to add in (e.g., WebKit.Cookie),
> but so far Webware is C-clean.
FWIW, There is a new date/time module being worked on for Python ,
hopefully for 2.3. For better or worse, there's no corresponding PEP, but
it is mentioned in the 2.3 release schedule/laundry list PEP (283) , and
there is a Wiki covering its development .
Jeffrey P Shell