[Python-Dev] PEP 495 accepted

[Tim Peters]

[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.