[issue20855] RFE: change bool(0.0) to evaluate as True

[Mark Dickinson]

Mark Dickinson added the comment:

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

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Nick Coghlan]

Nick Coghlan added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Tim Peters]

Tim Peters added the comment:

Excellent idea!  But then we should change bool(0.1) to be False too ;-)

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I thought literal copying was enough of a hint to humor without a smiley in the 
title.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy:  -belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Donald Stufft]

Donald Stufft added the comment:

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.

--
nosy: +dstufft
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20855] RFE: change bool(0.0) to evaluate as True

[Alexander Belopolsky]

New submission from Alexander Belopolsky:

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.

--
components: Interpreter Core
keywords: easy
messages: 212772
nosy: belopolsky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: RFE: change bool(0.0) to evaluate as True
type: enhancement
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com