Uhm... I think this thread is heading in the wrong direction.
Maybe from your POV, but from our POV the only way we can get time to work on Python is talk all of you into doing Zope work for Jim <wink>.
Fredrik wasn't proposing a solution to Jim's particular problem (whatever it was ;-), but instead opting for a solution of a large number of Python users out there.
I believe all /F is asking for is that all datetime types supply two specific methods, so that he can get the year etc out of anybody's datetime object via a uniform spelling. It's a fine idea.
... I would be willing to make the mxDateTime types subtypes of whatever Fredrik comes up with. The only requirement I have is that the binary footprint of the types needs to match todays layout of mxDateTime types since I need to maintain binary compatibility.
If /F is asking more than that datetime types implement a specific interface, he's got some major rewriting to do <wink>. Python doesn't have a good way to spell "interface" now, so think of it as a do-nothing base class, inheriting from which means absolutely nothing except that (a) you promise to supply the methods /F specified, and (b) /F can use isinstance to determine whether or not a given object supports this interface.
The other possibility would be adding a set of new types to mxDateTime which focus on low memory requirements rather than data roundtrip safety and speed.
That's getting back to what Jim wants. Maybe someone should ask him what that is <wink>.