[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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
