[Python-Dev] PEP 495 accepted (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Sep 22 22:25:31 CEST 2015

[Guido]

it is broken, due to the confusion about classic vs. timeline arithmetic -- these have different needs but there's only one > operator.

[Alex]

I feel silly trying to defend a design against its author. :-)

"Design" may be an overstatement in this specific case ;-)

I remember implementing this stuff, getting to the comparison operators, and noting that the spec was silent about what to do in case the tzinfos differed. I looked at Guido and explained that, and asked "so whaddya wanna do?".

One of us (I don't recall which) said "well, we could convert to UTC first - that would make sense". "Ya, sure," said the other. And I said "and then, of course, interzone subtraction should do the same." "Of course," said Guido, now annoyed that I was bothering him with the obvious ;-)

Note that, near that time, Python blithely compared any two objects, even if of wildly different types. Compared to that, doing anything arguably sane with datetime objects seemed wildly desirable. Ironically, the datetime implementation was Python's first library type to refuse to compare its objects to others of wildly different types.

So, in all, I'd say well under a minute's thought - between us - went into this decision. And we've been living in Paradise ever since :-)

Yes, a language with more than one > symbol would not have some of these problems. Similarly a language with a special symbol for string catenation would not have a non-commutative + and non- distributive *. All I am saying is that I can live with the choices made in datetime.

Given that the alternative is suicide, I approve of that life decision.

More information about the Python-Dev mailing list