[Python-Dev] Interop between datetime and mxDateTime

[Tim Peters]

[M.-A. Lemburg]
> I'd like to make mxDateTime and datetime in Python 2.3
> cooperate.

Cool!  Good luck <wink>.

> Looking at the datetime.h file, it seems that
> the C API isn't all that fleshed out yet. Will this happen
> before 2.3b1 ?

There are no plans to expand the C API.  Macros are provided for efficient
field extraction; all objects here are immutable so there are no macros for
changing fields; anything else needed has to go thru PyObject_CallMethod on
an existing datetime object, or (for construction) calling the type object.

> Related to this: I wonder why datetime is not a normal
> Python object which lives in Objects/ ?!

Didn't fit there.  Like, e.g., arraymodule.c and mmapmodule.c, it implements
a module the user needs to import explicitly (as well as supplying new
object types).  Nothing in Objects is like that (they don't implement
modules).

> Finally, the datetime objects don't seem to provide any
> means of letting binary operations with other types
> succeed. Coercion or mixed type operations are not
> implemented. When will this happen ?

Coercion is out of favor.  Binary datetime methods generally return
NotImplemented when they don't know how to handle an operation themself.  In
that case, Python then asks "the other" object to try the operation.  If
that also returns NotImplemented, *then* Python complains.

>>> date.today() + 12
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'datetime.date' and 'int'
>>>

That outcome means that date and int both got a crack at it, and both
returned NotImplemented.

Comparison is an exception to this:  in order to stop comparison from
falling back to the default compare-by-object-address, datetime comparison
operators explictly raise TypeError when they don't know what to do.
Offhand that seems hard (perhaps impossible) to worm around.