[Łukasz Rekucki <lreku...@gmail.com>] >> Maybe instead of trying to decide who is "wrong" and which approach is >> "broken", Python just needs a more clear separation between timezone >> aware objects and "naive" ones?
[Lennart Regebro <rege...@gmail.com>] > Well, the separation is pretty clear already. I preemptively ;-) agreed with Lukasz on this: it's downright strange that we have datetime objects the docs call "aware" that nevertheless _act_ as if they were "naive" in some cases of arithmetic. That was the intended design, but it is strange in that respect. So it goes. > Tim wants to have naive timezone aware objects, ie datetime objects that have > a time zone but ignores the time zone, except when converting to other time > zones. That's not about what I want. It's what Python _does_. We can't wish away how the language already works. Guido designed it that way (with an enormous amount of public input & debate), and I did the vast bulk of the implementations. It so happens I like Guido's design, but none of that ever depended on what Tim wanted datetime to do (except in minor respects, like adding the .replace() and .fromutc() methods, which weren't part of the original design - I made those up based on painful experience with many iterations of ever-changing prototypes - but my role in arithmetic was just to implement the design specs). > I have yet to see a use case for that. Of course you have. When you address them, you usually dismiss them as "calendar operations" (IIRC). In some of those cases, you correctly pointed out that the user could have done as well (based on all they explicitly revealed about their app's requirements) with a naive datetime object. In other cases, you made the same claim but seemingly incorrectly (like any app that needs to track the local clocks across multiple timezones with inter-zone conversions, and also needs to do "calendar operations" in those timezones, and - unsurprisingly! - uses Python's datetime arithmetic to implement such operations. It's unsurprising they do so because that was always the intended and documented way to do so - and it has always worked for these purposes). But it doesn't matter whether you _call_ them "calendar operations", or anything else. What they're called doesn't change any of the high-order bits: they are use cases, they already work, they have worked that way for a dozen years (an eternity in "computer time"), they were always intended to work that way, and the docs have always said they work that way. I do think you're missing my fundamental objection: no matter what intended and documented thing datetime (or any other module) has done all along, and regardless of whether I loved it or hated it, I'd be just as annoying about insisting we cannot intentionally break existing code using that thing in non-trivial ways without a justification so compelling that I can't recall a case of it ever happening. If Python had been doing "Lennart arithmetic" all along, and Guido proposed changing to "Guido arithmetic" in Python 2 and/or Python 3, I'd be equally opposed to his proposal (& despite that I prefer Guido's vision of how datetime arithmetic should work - "tough luck - it's too late". And he'd eventually agree. Be like Guido ;-) ). Given Guido's brief message, I'll cut the weasel words, confident that I'm still channeling his intent in this area: major backward-incompatible changes (like altering the meaning of arithmetic using already-existing objects and operations) are not going to happen. It's clear now that he'd even remain opposed to such a change in a hypothetical everything-can-change Python 4, because he still likes his original design. So please move on. New objects, new operations, new functions, new methods, new optional arguments on existing methods, even new modules ... all remain on the table. Changing the meaning of code that some users are perfectly happy with was never really _on_ the table (which would have been made clear before if the PEP had spelled out that changes to the results of arithmetic wouldn't be restricted to a tiny number of annoying-to-everyone-regardless edge cases). Even convincing _everyone_ that "it's broken" (which will never happen either) wouldn't change one jot of this. Look: >>> 0.1 + 0.1 + 0.1 == 0.3 False That will remain "broken" forever too (except, perhaps, until Python 4). and despite that it's one of the most frequent of all user complaints. So at worst you're in good company ;-) _______________________________________________ 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
