On Thu, Jul 30, 2015 at 6:03 PM, Tim Peters <[email protected]> wrote:
> [Guido]
> > ...
> > I also never meant the term "naive" to be used for the existing
> arithmetic
> > rules for tz-aware datetime objects -- I always meant "naive" to refer to
> > tz-less datetime objects.
>
> "Naive arithmetic" was my neologism, starting in this batch of
> messages. The docs don't call the arithmetic anything, or acknowledge
> that more than one kind of arithmetic is possible. This batch of
> messages needed to call it _something_, so I made something up.
>
Cool. I missed that one message out of 100s. :-)
> The docs do briefly explain the "native time" _model_ (and acknowledge
> that more than one kind of model is possible).
I assume you meant naive, not native.
> The kind of arithmetic
> Python implements is the only kind that delivers correct answers
> _within_ the naive time model,. so I've been calling it "naive
> arithmetic" - in the sense of "the arithmetic behavior required by the
> naive time model".
>
Sure.
> Which is an unfortunate verbal mess, in large part because "naive
> arithmetic" is used for _both_ what the docs call "naive objects" and
> "aware objects". Then again, calling _anything_ "naive" in the docs
> was probably also unfortunate from the start ;-)
>
It was definitely naive. :-)
> > I would prefer something like "classic arithmetic" for tz-aware datetime
> objects.
>
> Read literally, that doesn't make sense to me, and I can't tease out
> the intent. That is, calling an object (whatever it is) a kind of
> arithmetic (whatever it is) doesn't make sense to me. I had guessed,
> that you wanted to call the kind of _arithmetic_ currently implemented
> "classic arithmetic". but in the next sentence you seem to want to
> call that "human arithmetic":
>
And yet that is what I meant, i.e., calling the current arithmetic for
tz-aware objects classic, because I wanted to avoid naming it naive
(because of the aforementioned verbal mess).
> > We can then introduce two new terms for different forms of arithmetic:
> > "human arithmetic" for the form that can do things like "+ 2 months" in a
> > way that (mostly) matches human expectations, and "strict arithmetic" for
> > the form that Lennart needs (essentially move a specific number of
> seconds
> > along UTC).
>
> Do you really intend that we use all three: "classic arithmetic",
> "human arithmetic", and "strict arithmetic"?. If so, I don't grasp
> the intended distinction between "classic" and "human".(both seem to
> be the same as what I've been calling "naive arithmetic": the
> arithmetic Python currently implements for binary arithmetic operators
> involving at least one datetime object).
>
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.
(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. 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.)
> Anyway, because "strict arithmetic" more-or-less literally means
> "arithmetic that wholly satisfies the requirements of a given model",
> in isolation the phrase leaves the question of _which_ model open.
> So, as was suggested later in the thread, I'd prefer "timeline
> arithmetic" (and couldn't care less whether it's called "timeline",
> "time line", or both). And I'll conveniently overlook that "timeline
> arithmetic" on its own leaves open _which_ timeline (naive or
> timezone) is intended ;-)
>
Sure.
> > FWIW (not much, we're stuck with it now), my intention with classic
> > arithmetic was to approximate human arithmetic, but only for cases that
> > didn't require messy heuristics such as "Feb 29, 2016 plus one year" or
> "Jan
> > 31, 1956 minus 9 months".
>
> I always viewed the _model_ ("naive time") as primary. Specific
> arithmetic requirements (for builtin arithmetic operators) then
> necessarily followed from the choice of model. In any case, while
> mixed datetime/timedelta arithmetic supports only a small subset of
> what people want in the way of "calendar operations", it is an
> exceedingly useful subset on its own, _and_ in implementing fancier
> operations. It was a great start.
>
I agree. :-)
> ...
>
> > I also (naively :-) assumed that people interested in strict arithmetic
> would
> > just keep using the POSIX timestamps used by the time module.
>
>
>
> >> (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. My memory seems to be failing -- I also thought there
was a datetime PEP, 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? :-)
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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/
