[Guido] > .... > I assume you meant naive, not native. Always. In any context ;-)
BTW, the only thing truly naive about datetime was how little time everyone expected its development to consume. 13 years later and a billion people are still arguing over how to finish implementing mathematically trivial timezone arithmetic ;-) > Yes, I meant to introduce human arithmetic as a third form, to support > adding e.g. months or years, while classic and strict arithmetic shouldn't. Got it. > (Since timedelta doesn't keep its days and seconds separated, it's not > really a Period, so I think it shouldn't be extended further. Absolutely not. It's just a funky way to spell a large integer (number of microseconds), and it's only in naive time that _any_ common named durations longer than an hour actually match a fixed number of microseconds. The only new argument I think we _could_ sanely add to the timedelta constructor is `fortnights=`. Well, that and `googoldays=`, except that would overflow for any non-zero value. So it goes: patch on the way! ;-) > And adding months is a requirement for human arithmetic -- e.g. I was > called a bad word on Twitter yesterday because timedelta doesn't support > months.) Thanks for telling me! It's another excellent reason to keep my life blissfully Twitter-free. >>>> (BTW, historically, early versions of Python datetime had a separate >>>> datetime subclass called datetimetz (IIRC), but the final design got >>>> rid of this unnecessary complexity.) >>> I don't believe that was ever released, but it's possible we >>> contemplated that and even implemented it in an early >>> pure-Python prototype. >> FWIW, IIRC it did exist in an early prototype but was discarded before >> it was even halfway implemented. > I stand corrected. Na. I could well be wrong about everything. Much of my few lucid moments are lost to bemoaning all I've forgotten. > My memory seems to be failing -- I also thought there was a datetime > PEP, Oops! It really is failing! There definitely was not. > but I guess we avoided the PEP process (even though datetime > was added in 2.3, well after PEP 1 was written) because we were > all working in the same office. (Or do I misremember that too? :-) Nobody could have made time to write a PEP. We were utterly drowning in "input" without one. Lots of discussion took place on a Zope-hosted public DateTime wiki. Yesterday I tried pretty hard to find it without success - I guess it's lost now. Also enormous wads of Python and Zope mailing list traffic. And what ended up being the text of the first version of the manual docs was written by me in a markup-free plain text file that was checked in and publicized frequently, kept roughly in synch with the ever-changing Python prototype and test suite. None of those three ever get "too far" ahead of the others. So everyone interested got plain-text docs, a prototype, and a test suite, all along the way, plus wiki and multiple mailing list access for questions, requests and discussions. Besides, it was your project. There wasn't much suspense over whether it would be accepted ;-) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
