[Guido] > The proposal also recomments an abstract base type, "basetime", for > all time types. Without this, cmp() is hard to do (see Tim's post for > explanation; we don't want datetime objects to be comparable to > objects with arbitrary other types, because the default comparison iss > meaningless). > > This could be a pure "marker" type, like "basestring". Marc-Andre, > if we export basetime from the core, can mxDateTime subclass from > that? Let me ask a question: when I tried to make datatime.tzinfo a pure "marker" type, I eventually had to give up, because I absolutely could not make it work with pickling (and recalling that pickles produced by datetime.py had to be readable by datetimemodule.c, and vice versa). Instead I had to make it instantiable (give it an init method that didn't complain), and require that tzinfo subclasses also have an __init__method callable with no arguments. Are we able to get away with basestring because pickle already has deep knowledge about Python's string types? [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?
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