[Python-Dev] proposal: add basic time type to the standard library
Fredrik Lundh
fredrik@pythonware.com
Sat, 9 Feb 2002 12:21:00 +0100
mal wrote:
> In order to make mxDateTime subtypes of this new type we'd need to
> make sure that the datetime type uses a true struct subset of what
> I have in DateTime objects now:
>
> typedef struct {
> PyObject_HEAD
>
> /* Representation used to do calculations */
> long absdate; /* number of days since 31.12. in the year 1 BC
> calculated in the Gregorian calendar. */
> double abstime; /* seconds since 0:00:00.00 (midnight)
> on the day pointed to by absdate */
>
> ...lots of broken down values needed to assure roundtrip safety...
>
> }
as Tim has pointed out, what I have in mind is:
typedef struct {
PyObject_HEAD
/* nothing here: subtypes should implement timetuple
and, if possible, utctimetuple */
} basetimeObject;
/* maybe: */
PyObject*
basetime_timetuple(PyObject* self, PyObject* args)
{
PyErr_SetString(PyExc_NotImplementedError, "must override");
return NULL;
}
(to adapt mxDateTime, all you should have to do is to inherit from
baseObject, and add an alias for your "tuple" method)
:::
since it's really easy to do, we should probably also add a simpletime type
to the standard library, which wraps the standard time_t:
typedef struct {
PyObject_HEAD
time_t time;
/* maybe: int timezone; */
} simpletimeObject;
:::
What I'm looking for is "decoupling", and making it easier for people
to experiment with different implementations.
Things like xmlrpclib, the logging system, database adapters, etc
can look for basetime instances, and use the standard protocol to
extract time information from any time object implementation.
(I can imagine similar "abstract" basetypes for money/decimal data
-- a basetype plus standardized behaviour for __int__, __float__,
__str__ -- and possibly some other data types: baseimage, base-
sound, basedomnode, ...)
Hopefully, such base types can be converted to "interfaces" when-
ever we get that. But I don't want to wait for a datetime working
group to solve everything that MAL has already solved in mxDate-
Time, and then everything he hasn't addressed. Nor do I want to
wait for an interface working group to sort that thing out.
Let's do something really simple instead.
</F>