pep proposal : A date object for the standard library

[M.-A. Lemburg]

Robin Becker wrote:
> 
> In article <3C110867.5263E6E6 at attbi.com>, Chris Barker
> <chrishbarker at attbi.com> writes
> .....
> >
> >Are there other technical issues with mxDateTime that make it unsuitable
> >for the standard lib?
> >
> ....
> the only problem with mx datetime is that the individual objects require
> quite a lot of storage. Last time I heard it was 32 bytes, but I'm not
> sure whether that is over and above what python needs for an object or
> includes it.

DateTime objects are rather largish because they cache many
of the broken down values.

Note that mxTools has an API which allows querying the size of
the internal Python object (provided it's not of varying size;
allocated buffers aren't counted either): mx.Tools.sizeof().
 
> Some business time series have thousands of entries and for intra day
> stuff there is no obvious frequency which would allow a convenient
> sparse representation of the times. Is storage an issue? Certainly time
> series analysis nerds think so, but if it's only a factor of 4 I guess
> it won't matter to pythoneers.

For large series, you can convert DateTime objects to either
tuples (absdate, abstime), absdays (which is a float) or
a COM date float.

One of the reasons for not putting mxDateTime into the core is 
that it's simply too big (even though the implementation which
is considered in the PEP wouldn't be any smaller ;-). The other
is that it's integral part of the eGenix mx BASE package
and I don't want to rip that apart; I also have a different
update cycle compared to core Python.

Just curious: Why not simply leave things the way thy are
and wait for someone to revive the old Sumo Python Distribution
idea ?!

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/