[Tim] > [Mark Hammond] > > I have the exact same issue for my COM time objects, and > like MAL, just > > recently started thinking about it. > > > > Certainly, such a subclass would help me enormously, and would > > probably make it quite simple for this to allow *any* datetime > > object to be passed to COM/Windows functions. > > Well, I don't see that a basetime marker class alone would > allow for that. > What else are you assuming? Well, at the very least I expect that I could do *something* <wink>. If I get an object of this type passed to my extension, I at least know it is *some* kind of time object, so poke-and-hope can kick in. There is an excellent chance, for example, that a "timetuple()" method exists. Certainly being able to deal explicitly only with mxDateTime and Python's datetime, without needing to link to either, would still be a huge win. So yeah, having more of a datetime *interface* would be nicer than a marker type, but given a base type and a clear convention for datetime objects, we are pretty close. On the other hand, I guess *just* the existance of a "timetuple()" method is as good an indicator as any. What-goes-around-comes-around ly, Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4