[Lennart Regebro firstname.lastname@example.org]
Of course, I meant datetime objects. In everything else, I stand by my original claim. If you want naive datetime obejcts, you should use naive datetime objects.
That's tautological ("if you want X, you should use X"). I'm not sure what you intended to say. But it's a fact that some apps do need DST-aware datetime objects, and also need naive datetime arithmetic on those objects. The point isn't that there's no way to get the latter if Python datetime arithmetic changed; the point is that it _already works_ for them, and has for 12 years. You can't break apps without overwhelmingly compelling reason(s). Please move on to think about backward-compatible ways to get what you want instead.
In the meantime, writing little functions to do the convert/arithmetic/convert dance is "the obvious" way to get what you want.
My opinion is and remains that intentionally breaking datetime arithmetic to make non-naive objects behave in a naive way was a mistake.
While other people think it was a fine and useful compromise. It's certainly fortunate that repetition changes minds ;-) Regardless, that decision is ancient history now.