classification
Title: RFE: change bool(0.0) to evaluate as True
Type: enhancement Stage: needs patch
Components: Interpreter Core Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: dstufft, mark.dickinson, ncoghlan, tim.peters, yselivanov
Priority: normal Keywords: easy

Created on 2014-03-05 22:50 by belopolsky, last changed 2014-03-06 08:39 by mark.dickinson. This issue is now closed.

Messages (6)
msg212772 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-03-05 22:50
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 subtle data driven behavioural bug that only occurs exactly at 0x0.0p+0.

If someone wants to write the patch to deprecate this behaviour in Python 3.5 (reporting a deprecation warning whenever midnight is interpreted as False, perhaps suggesting the use of "is" or "is not" instead), and then actually change the behaviour in 3.6, I don't believe we should actively oppose them from doing so.

See also issue #13936.
msg212773 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-03-05 22:56
Being passive aggressive is pointless, if you disagree then discuss on the actual issue or on the mailing list thread. Opening up random issues because you're mad just makes you look like a child.
msg212774 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-03-05 22:59
I thought literal copying was enough of a hint to humor without a smiley in the title.
msg212775 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2014-03-05 23:03
Excellent idea!  But then we should change bool(0.1) to be False too ;-)
msg212776 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-03-05 23:24
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 concrete *use case* given for it. This is in stark contrast to the other types where treating zero or an empty container differently is quite common, and hence generally unsurprising.

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 for datetime.time objects. This is particularly likely for newer users that don't have experience with lower level models of time of day as "seconds since midnight" (which is the mental model where the current behaviour makes sense, and the most plausible rationale for its origins).
msg212795 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-06 08:39
I realise this was opened as a joke, but I actually consider this suggestion to be unridiculous.  I've never felt comfortable with code that does  "if x" rather than "if x != 0.0"  for x a float.

What really makes this a no-go in Python is the equality between floats and ints, and then between ints and bools.  If we want to maintain the invariant that  x == y implies  bool(x) == bool(y)  then we end up making bool(0) and bool(False) true, the latter of which is clearly ridiculous.

So not in Python, but perhaps in some other Python-like language with a notion of 'boolean context'.
History
Date User Action Args
2014-03-06 08:39:20mark.dickinsonsetnosy: + mark.dickinson
messages: + msg212795
2014-03-05 23:24:51ncoghlansetmessages: + msg212776
2014-03-05 23:03:14tim.peterssetnosy: + tim.peters
messages: + msg212775
2014-03-05 22:59:35yselivanovsetnosy: + yselivanov
2014-03-05 22:59:23belopolskysetnosy: - belopolsky
2014-03-05 22:59:13belopolskysetmessages: + msg212774
2014-03-05 22:56:01dstufftsetstatus: open -> closed

nosy: + dstufft
messages: + msg212773

resolution: not a bug
2014-03-05 22:50:10belopolskycreate