[Python-Dev] proposal: add basic time type to the standard library (original) (raw)

M.-A. Lemburg mal@lemburg.com
Tue, 26 Feb 2002 21:20:56 +0100

Jim Fulton wrote:

"M.-A. Lemburg" wrote: > > Jim Fulton wrote: ... > > What is data roundtrip safety? > > Roundtrip safety means that e.g. if you take a COM date value > from a ADO and create a DateTime object with it, you can > be sure to get back the exact same value via the COMDate() > method. Since I don't know what COMDate is, this doesn't mean anything to me. :)

Then you're lucky -- COMDates are just about the strangest beast I've ever seen as date/time encoding.

... > I suppose that I could easily make a few calculation > lazy to enhance speed; memory footprint would not change > though. It's currently at 56 bytes per DateTime object > and 36 bytes per DateTimeDelta object.

Does that include the two words of Python object overhead?

I suppose so -- the values I quoted are the tp_size values of the types. The instance will probably also require a dictionary and the weak ref list on top of those figures.

> To get similar accuracy in Python,

I assume you mean precision.

Eh, yes.

> you'd need a float and > an integer per object,

It depends on the desired precision. To get minute precision, an int will do. Two ints can get you about a hundreth of a microsecond precision, which is more than most people need.

I was just trying to compare apples to apples :-)

mxDateTime offers the same precision as a float (for daytime) and an integer (for the day) can give.

> that's 16 bytes + 12 bytes == 28 bytes > + malloc() overhead for the two and the wrapping instance > which gives another 32 bytes (provided you store the two > objects in slots)... >60 bytes per Python based date time > object.

A Python-based date-time object isn't very interesting to me.

You should have mentioned that earlier ;-)

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/