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

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

STINNER Victor added the comment: New changeset 857d573257ab150d6bea666354312a5fd284b171 by Victor Stinner in branch '3.7': bpo-39932: Fix multiprocessing test_heap() (GH-19690) https://github.com/python/cpython/commit/857d573257ab150d6bea666354312a5fd284b171 --

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

Change by STINNER Victor : -- keywords: +patch pull_requests: +19010 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19690 ___ Python tracker ___

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

test_multiprocessing_fork leaked [31, 23, 14] memory blocks, sum=68 test_multiprocessing_fork leaked [2, 0, 0] file descriptors, sum=2 test_multiprocessing_fork failed Run 2: 1 test OK. Run 6: test_multiprocessing_fork leaked [0, 2, 0] file descriptors, sum=2 test_multiprocessing_fork failed

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

STINNER Victor added the comment: On aarch64 RHEL8 Refleaks 3.7, I managed to reproduce the issue with a single test: ./python -m test test_multiprocessing_fork -R 3:3 -m test.test_multiprocessing_fork.WithProcessesTestHeap.test_heap -v -- ___

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

STINNER Victor added the comment: Bug seen on Pytho 3.7 branch, on Fedora Stable, RHEL7 and RHEL8, on different architectures. aarch64 RHEL7 Refleaks 3.7: https://buildbot.python.org/all/#builders/598/builds/22 PPC64LE RHEL7 Refleaks 3.7:

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

STINNER Victor added the comment: Another example on PPC64LE RHEL8 Refleaks 3.7: https://buildbot.python.org/all/#/builders/431/builds/29 Warning -- Dangling processes: {} Warning -- Dangling processes: {} test_multiprocessing_spawn leaked [0, 2, 0] file descriptors, sum=2 Re-running

[issue39932] test_multiprocessing_fork leaked [0, 2, 0] file descriptors on aarch64 RHEL8 Refleaks 3.7 buildbot

New submission from STINNER Victor : aarch64 RHEL8 Refleaks 3.7: https://buildbot.python.org/all/#/builders/620/builds/20 test_multiprocessing_fork leaked [0, 2, 0] file descriptors, sum=2 0:40:22 load avg: 0.93 Re-running failed tests in verbose mode 0:40:22 load avg: 0.93 Re-running

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

STINNER Victor added the comment: FYI this bug was found in paraview in Fedora Rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1743896 -- ___ Python tracker ___

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

STINNER Victor added the comment: I tested my fix manually using example from msg350262 and gcc -O3 (./configure && make): I can reproduce the crash without the change, and I confirm that my change fix the crash. Thanks Miro for the bug report: the fix will be included in next Python 3.8

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

STINNER Victor added the comment: New changeset ca9ae94a2aba35d94ac1ec081f9bcac3a13aebd3 by Victor Stinner in branch '3.8': bpo-37926: Fix PySys_SetArgvEx(0, NULL, 0) crash (GH-15415) (GH-15420) https://github.com/python/cpython/commit/ca9ae94a2aba35d94ac1ec081f9bcac3a13aebd3

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

Change by STINNER Victor : -- pull_requests: +15120 pull_request: https://github.com/python/cpython/pull/15420 ___ Python tracker ___

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

STINNER Victor added the comment: New changeset c48682509dc49b43fe914fe6c502bc390345d1c2 by Victor Stinner in branch 'master': bpo-37926: Fix PySys_SetArgvEx(0, NULL, 0) crash (GH-15415) https://github.com/python/cpython/commit/c48682509dc49b43fe914fe6c502bc390345d1c2

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

STINNER Victor added the comment: Oops, it's my fault! PR 15415 fix the crash. The regression was introduced by: commit 74f6568bbd3e70806ea3219e8bacb386ad802ccf Author: Victor Stinner Date: Fri Mar 15 15:08:05 2019 +0100 bpo-36301: Add _PyWstrList structure (GH-12343) Simplified

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

Change by STINNER Victor : -- keywords: +patch pull_requests: +15117 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15415 ___ Python tracker ___

[issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function

New submission from Miro Hrončok : There is a regression between Python 3.7 and 3.8 when using PySys_SetArgvEx(0, NULL, 0). Consider this example: #include int main() { Py_Initialize(); PySys_SetArgvEx(0, NULL, 0); /* HERE */ PyRun_SimpleString("from time import time,ct

[issue34808] bytes[0] != bytes[0:1]

ucyo added the comment: Thank you for the answer. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue34808] bytes[0] != bytes[0:1]

Geoffrey Spear added the comment: Indexing bytes giving an int is a feature. Some might argue it's a bad feature, but it was done on purpose. -- nosy: +geoffreyspear ___ Python tracker

[issue34808] bytes[0] != bytes[0:1]

New submission from ucyo : bytes('sdf', 'UTF8')[0] != bytes('sdf', 'UTF8')[0:1] # FALSE 'sdf'[0] != 'sdf'[0:1] # TRUE Is this a feature or bug. I would have expected the same behaviour. -- components: Library (Lib) messages: 326446 nosy: ucyo priority: normal severity: normal status

Re: 0 + not 0

Ian Kelly wrote: I must concur. The grammar as written does not actually produce 1 + not 0. I think it's still worthwhile opening a bug, because the behavior is surprising and possibly not intentional. It's almost certainly intentional. If you want not a + b c to be interpreted

Re: 0 + not 0

On 11-7-2015 12:38, Irmen de Jong wrote: On 11-7-2015 12:26, candide wrote: 0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? I would say that the boolean operator 'not' cannot occur in an arithmetic

Re: 0 + not 0

Le samedi 11 juillet 2015 13:31:03 UTC+2, Luuk a écrit : But operator precedence of 'not' is higher than of '+' Right but what does this prove? For instance, unary minus has higher precedence than exponentiation but the expression 2 ** -1 doesn't raise a syntax error. --

Re: 0 + not 0

On Sat, Jul 11, 2015 at 9:54 PM, candide c.cand...@laposte.net wrote: Le samedi 11 juillet 2015 13:31:03 UTC+2, Luuk a écrit : But operator precedence of 'not' is higher than of '+' Right but what does this prove? For instance, unary minus has higher precedence than exponentiation

Re: 0 + not 0

'+'. But, it gets confusing.. not 0 + 1 False not 0 True True + 1 2 i would expect 'not 0 + 1' to return the same value as 'True + 1' (not 0 + 1) == (not (0 + 1)) ChrisA -- https://mail.python.org/mailman/listinfo/python-list

0 + not 0

0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? -- https://mail.python.org/mailman/listinfo/python-list

Re: 0 + not 0

the table; 'not' has *lower* precedence than '+'. But, it gets confusing.. not 0 + 1 False not 0 True True + 1 2 i would expect 'not 0 + 1' to return the same value as 'True + 1' (not 0 + 1) == (not (0 + 1)) ChrisA But operator precedence of 'not' is higher than

Re: 0 + not 0

Le samedi 11 juillet 2015 13:21:03 UTC+2, Chris Angelico a écrit : I think you're misreading the table; 'not' has *lower* precedence than '+'. Right but Python docs helps a lot in misreading ;) Following the iconicity principle, it's pretty obvious that one has to display table priority

Re: 0 + not 0

On 11-7-2015 12:26, candide wrote: 0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? I would say that the boolean operator 'not' cannot occur in an arithmetic expression. Maybe you meant to use

Re: 0 + not 0

On Sat, Jul 11, 2015 at 8:26 PM, candide c.cand...@laposte.net wrote: 0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? I'm actually not sure why this can't be handled. Possibly it's a limitation of the parser

Re: 0 + not 0

Le samedi 11 juillet 2015 14:05:58 UTC+2, Chris Angelico a écrit : You'll see down below a footnote referring to this as a special case. I didn't spot the footnote and I don't regard it as dealing with a special case: the footnote is paraphrasing the precedence hierarchy given by the table. I

Re: 0 + not 0

On 11.07.15 13:26, candide wrote: 0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? This looks as a bug to me. Please file a report on http://bugs.python.org. -- https://mail.python.org/mailman/listinfo

Re: 0 + not 0

On 2015-07-11 17:02, Stefan Ram wrote: Serhiy Storchaka storch...@gmail.com writes: On 11.07.15 13:26, candide wrote: 0 + not 0 File stdin, line 1 0 + not 0 ^ SyntaxError: invalid syntax What is syntactically wrong with 0 + not 0? This looks as a bug to me. Please file

Re: 0 + not 0

Le samedi 11 juillet 2015 15:38:51 UTC+2, Serhiy Storchaka a écrit : This looks as a bug to me. Please file a report on http://bugs.python.org. OK, I'll report. -- https://mail.python.org/mailman/listinfo/python-list

Re: 0 + not 0

On Sat, Jul 11, 2015 at 10:02 AM, Stefan Ram r...@zedat.fu-berlin.de wrote: I look at Python 3.4.3: a_expr ::= m_expr | a_expr + m_expr | a_expr - m_expr So, »not 0« must be an »m_expr« when used as the right operand of »+«. m_expr ::= u_expr | m_expr * u_expr | m_expr // u_expr

Re: 0 + not 0

On 11/07/2015 17:56, Ian Kelly wrote: On Sat, Jul 11, 2015 at 10:02 AM, Stefan Ram r...@zedat.fu-berlin.de wrote: I look at Python 3.4.3: a_expr ::= m_expr | a_expr + m_expr | a_expr - m_expr So, »not 0« must be an »m_expr« when used as the right operand of »+«. m_expr ::= u_expr

Re: 0 + not 0

On Sat, Jul 11, 2015, at 07:20, Chris Angelico wrote: On Sat, Jul 11, 2015 at 9:12 PM, Luuk l...@invalid.lan wrote: It can occur in an arithmetic expression, and 'not' has a higher precedence than '+' (https://docs.python.org/2/reference/expressions.html#operator-precedence) I think

[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

(datetime.time(0, 0, 0)) to evaluate as True ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list mailing list Unsubscribe: https

[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

the utc offset and convert that to minutes, then subtract the second from the first and if that is zero it is False. So if you take -5 for instance (my own timezone!) the equation to determine when the False time is would look like: x - (-5 * 60) = 0 x - (-300) = 0 x + 300 = 0 x = -300 So we'd

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

also worth noting the current behaviour in boolean context is effectively shorthand for: import datetime as dt naivemidnight = dt.time(0, 0) utcmidnight = dt.time(0, 0, tzinfo=dt.timezone.utc if x in (naivemidnight, utcmidnight): ... So if the current boolean behaviour

[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] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ 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

)] += 1 I see nothing wrong with this code and I don't think rewriting it as if dt.time() != datetime.time(0): .. is an improvement. This has resulted in a problem, since the default for most types is that all instances are true, and users mistakenly assume that assumption will hold

[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

notations for those: 24:00 and 00:00. Python does not allow time(24), so an application that considers midnight to be the last moment of the day has to treat time(0) exceptionally. See also #10427. -- ___ Python tracker rep...@bugs.python.org http

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

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

to those of 0, , or the empty set. Time values cannot be added or multiplied. Midnight evaluting to false makes as much sense as date(1,1,1) -- the minimal valid date value -- evaluating to false (and it doesn't). It makes perfect sense for timedelta(0) to evaluate to false, and it does. time

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

for is timeobj midnight or false? Would that ever be useful in practice? If you are indeed checking for midnight, surely if timeobj == time(0, 0): would be the most explicit and obvious way to do it? -- nosy: +Andreas.Pelme ___ Python tracker rep

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Alexander Belopolsky added the comment: Please reopen. Please bring your case to python-ideas. All developers who commented on this issue agree that it is invalid. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

of the | symbol evaluates to False. That makes sense in almost all of the cases. In the case of the `datetime.time(0, 0)` object, the default value is displayed, even though `datetime.time(0, 0).__str__()` results in a valid string (in this case '00:00:00'). (By the way, through these experiments I

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___ Python-bugs-list

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

New submission from Lakin Wecker lakin.wec...@gmail.com: midnight is represented by datetime.time(0,0,0). However, this time (unlike all other valid times, including datetime.time(0,0,1)) evalutes to false in if conditions: import datetime if datetime.time(0,0,0): print

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker lakin.wec...@gmail.com added the comment: I'm updating the versions to the ones that I've actually tried it on - this is not an exhaustive search at this point. -- versions: +Python 2.6, Python 2.7 ___ Python tracker

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Lakin Wecker lakin.wec...@gmail.com: -- components: +Library (Lib) type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

R. David Murray rdmur...@bitdance.com added the comment: I don't think I would have ever thought of testing a datetime for its truth value. But the behavior you observe is consistent with the rest of Python: 0 is false. I wonder if this is by design or by accident. -- nosy

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936 ___ ___

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker lakin.wec...@gmail.com added the comment: Right. I've updated my code to be more correct: instead of: if not start_time: start_time = default_time it now reads: if start_time is None: start_time = default_time which operates correctly and works fine for my case, I just

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Georg Brandl ge...@python.org added the comment: It must be by design -- someone has implemented a __bool__ (formerly __nonzero__) method; otherwise all objects would be true. -- nosy: +georg.brandl, lemburg ___ Python tracker rep...@bugs.python.org

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Georg Brandl ge...@python.org added the comment: BTW, being a valid time is not a good argument: 0, or False are all valid instances of their types. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13936

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Alexander Belopolsky alexander.belopol...@gmail.com added the comment: This is by design. I don't have a reference, but I do remember this being discussed. Suggestions for improving the documentation are welcome. -- ___ Python tracker

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Tim Peters tim.pet...@gmail.com added the comment: From the docs, at: http://docs.python.org/library/datetime.html#time-objects in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None

  1   2   >