[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg405699 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Change by Eryk Sun : -- components: +Library (Lib) -Tkinter nosy: -ahmedsayeed1982 ___ Python tracker ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Ahmed Sayeed added the comment: However, this isn't a trivial change. http://www-look-4.com/category/property/ So to fix the known issue quickly (including in the gdb 10 branch), this patch just disables all dwarf2_per_bfd sharing for objfiles using READNOW.

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by lilydjwg lilyd...@gmail.com: -- nosy: +lilydjwg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list mailing

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Roundup Robot added the comment: New changeset 89aa669dcc61 by Benjamin Peterson in branch 'default': remove the ability of datetime.time to be considered false (closes #13936) http://hg.python.org/cpython/rev/89aa669dcc61 -- nosy: +python-dev resolution: - fixed stage: -

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Justin Brown added the comment: This behavior conflicts with the other major classes, datetime.date and datetime.datetime. The ostensible reason for this falsy behavior is that midnight represents a fundamental zero point. We should expect to see similar zero points that evaluate to False for

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: More proposals from the thread (paraphrased): - make any aware time() object always True (leave naive midnight as False) - make any aware time() object with a non-zero UTC offset always True (leave naive midnight and UTC midnight as False) - deprecate aware

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Current status of thread discussion (yes, I'm biased, and that shows in the phrasing below): Arguments raised for status quo: - the module is behaving exactly as described in the documentation - removing false time values will require affected users to update

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Skip Montanaro added the comment: the current behaviour takes something that would be a harmless style error for most structured data types ... I'm not sure what a structured data type is, but in my mind the original poster's construct is more than a style error. He was using None as a

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Structured data is just a shorthand way of referring to any Python object which is neither a number or a container and exhibits the default boolean behaviour where all instances are true. The problem datetime.time is both that its current behaviour is internally

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

R. David Murray added the comment: it wasn't an accident, it was designed so modulo arithmetic could reasonably be implemented for time() objects (which hasn't been demanded or implemented since the datetime module was created) Ah, interesting. I just wrote a program last month where I

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Antoine Pitrou added the comment: Otherwise I'm pretty sympathetic to the RFE, but I'd really like time arithmetic to work, so I guess I'd have to be -1 in that case, wouldn't I? Adding times of the day sounds as well-defined to me as adding centigrade temperatures. --

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

R. David Murray added the comment: As does adding dates. I'm talking about timedelta arithmetic, just like for datetimes. I believe that still requires modulo arithmetic :) -- ___ Python tracker rep...@bugs.python.org

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: On Mar 7, 2014, at 10:12 AM, R. David Murray rep...@bugs.python.org wrote: I asked about it on IRC and someone said it was because arithmetic on times was ambiguous because of timezones, and I just accepted that rather than wonder why it hadn't

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: On Mar 7, 2014, at 10:15 AM, Antoine Pitrou rep...@bugs.python.org wrote: Adding times of the day sounds as well-defined to me as adding centigrade temperatures. What is wrong with adding temperatures? Climate people do it all the time when

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Tim Peters added the comment: [Nick] - deprecate aware time() entirely (raises the thorny question of what to return from .time() on an aware datetime() object) aware_datetime_object.time() already returns a naive time object. The thorny question is what .timetz() should return - but if

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Westley Martínez aniko...@gmail.com: -- nosy: +westley.martinez ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Ethan Furman added the comment: If no one else has gotten to this in the next six months or so, I will. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Westley Martínez added the comment: So is the plan to deprecate this in 3.5 and remove in 3.6? If so, the question is where should the deprecation be thrown? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Mark Lawrence added the comment: There is no plan, other than the BDFL asking for a survey of what is happening with code that relies on this in the real world. FTR I'm completely against this change. I see no reason to change something that's been in use for maybe nine years and does what

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: To be specific, Guido said that if this 3.0 or 3.1 he'd be all for changing it, and the only question in his mind is how safe it is change. And that his intuition is that it's a nuisance feature and few people have actually relied on it and that he'd be OK

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Mark, we kinda proved we're willing to break backwards compatibility in the name of improving usability when we embarked down the path of creating Python 3 and an associated transition plan from Python 2, rather than just continuing to develop Python 2.

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Antoine Pitrou added the comment: I agree that having midnight evaluate to false is completely unexpected and unintuitive. I can imagine situations where it bites people in production use in the uncommon case that a time is exactly equal to midnight. -- nosy: +pitrou

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Marc-Andre Lemburg added the comment: On 06.03.2014 10:30, Antoine Pitrou wrote: Antoine Pitrou added the comment: I agree that having midnight evaluate to false is completely unexpected and unintuitive. I can imagine situations where it bites people in production use in the uncommon

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Donald did some additional testing, and it turns out that it is specifically midnight *UTC* that is false in boolean context. For a TZ aware time, the false time depends on the offset (e.g. it would be false at 10 am here in Brisbane). --

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: It's actually a bit worse than that Nick. It's midnight UTC, as long as the UTC offset is Positive or Zero. This is because the way the check is implemented is naive. It's implemented as: Take the time portion sans the tzinfo and convert to minutes, then take

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: I wrote up a longer post on python-ideas regarding the problems that the current behaviour poses when it comes to inferring a correct mental model for datetime.time(): https://mail.python.org/pipermail/python-ideas/2014-March/026647.html As part of that, it's

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list mailing

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Hanxue Lee leehan...@gmail.com: -- nosy: +Hanxue.Lee ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Rewording the issue title and reopening based on the python-ideas thread. The rationale for making this change is that the current behaviour converts a stylistic problem in checking values against a sentinel via bool(value) instead of value is not None into a

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Donald Stufft don...@stufft.io: -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list mailing

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: -belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Nick Coghlan added the comment: Discussion in #20855 made me realise that any deprecation warning should explain how to convert a time object to seconds since midnight. That model of time of day is the most likely origin of the current behaviour, and explicit conversion to that form would be

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Stefan Krah added the comment: I like the current behavior. We have modulo arithmetic here and bool(96%24) is false, too. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: It's not modulo arithmetic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Stefan Krah added the comment: Unix time modulo 86400 gives the number of elapsed seconds in a day and is zero at midnight. Also, modular arithmetic is colloquially called clock arithmetic for a reason. -- ___ Python tracker rep...@bugs.python.org

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Amber Yust added the comment: Yes, but a datetime.time object is definitely not UNIX time. -- nosy: +Amber.Yust ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: #20855 was meant as a joke, so I'll keep serious responses here. Nick wrote: Alexander, my goal is to flip the default assumption in the time discussion. It is clear from the documentation that the current behaviour is intentional, but there is no

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: I am not even sure what that is supposed to be doing... You're trying to count midnight as the previous day instead of the actual day? That seems extremely contrived. -- ___ Python tracker rep...@bugs.python.org

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: Nick wrote: any deprecation warning should explain how to convert a time object to seconds since midnight. I would like to see such an explanation regardless of the outcome here. The best I can think of is timedelta(hours=t.hour, minutes=t.minute,

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: You're trying to count midnight as the previous day instead of the actual day? yes That seems extremely contrived Why? Midnight can be considered to be the last moment of the day or the first moment of the day. In ISO standard there are separate

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: If Midnight is considered the last moment of the day then it evaluating to false makes even less sense since the rationale given is time is seconds since midnight. However if you're considering it the last moment then time would be seconds since 12:01. So in

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Donald Stufft added the comment: Infact I would argue that ``if dt.time() != datetime.time(0):`` *would* be an improvement to that code because it is more accurately describing what you actually intend in the same way that ``if time_or_none is None`` would be an improvement to that code

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: If Midnight is considered the last moment of the day then it evaluating to false makes even less sense since the rationale given is time is seconds since midnight. You are erecting a straw-man. Python clearly considers time(0) to be the first moment

[issue13936] RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True

Alexander Belopolsky added the comment: So in that case your example using midnight as false is even more confusing and even more wrong than not using ``is None`` on the conditional check. I should have added that dt is a datetime instance and therefore dt.time() is None is always false.