Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: change bool(0.0) to evaluate as True #65054

Closed
abalkin opened this issue Mar 5, 2014 · 6 comments
Closed

RFE: change bool(0.0) to evaluate as True #65054

abalkin opened this issue Mar 5, 2014 · 6 comments
Labels
easy interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@abalkin
Copy link
Member

abalkin commented Mar 5, 2014

BPO 20855
Nosy @tim-one, @mdickinson, @ncoghlan, @1st1, @dstufft

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-03-05.22:56:01.005>
created_at = <Date 2014-03-05.22:50:10.066>
labels = ['interpreter-core', 'easy', 'type-feature', 'invalid']
title = 'RFE: change bool(0.0) to evaluate as True'
updated_at = <Date 2014-03-06.08:39:20.759>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2014-03-06.08:39:20.759>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2014-03-05.22:56:01.005>
closer = 'dstufft'
components = ['Interpreter Core']
creation = <Date 2014-03-05.22:50:10.066>
creator = 'belopolsky'
dependencies = []
files = []
hgrepos = []
issue_num = 20855
keywords = ['easy']
message_count = 6.0
messages = ['212772', '212773', '212774', '212775', '212776', '212795']
nosy_count = 5.0
nosy_names = ['tim.peters', 'mark.dickinson', 'ncoghlan', 'yselivanov', 'dstufft']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'needs patch'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue20855'
versions = ['Python 3.5']

@abalkin
Copy link
Member Author

abalkin commented Mar 5, 2014

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 bpo-13936.

@abalkin abalkin added interpreter-core (Objects, Python, Grammar, and Parser dirs) easy type-feature A feature request or enhancement labels Mar 5, 2014
@dstufft
Copy link
Member

dstufft commented Mar 5, 2014

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.

@dstufft dstufft closed this as completed Mar 5, 2014
@dstufft dstufft added the invalid label Mar 5, 2014
@abalkin
Copy link
Member Author

abalkin commented Mar 5, 2014

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

@tim-one
Copy link
Member

tim-one commented Mar 5, 2014

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

@ncoghlan
Copy link
Contributor

ncoghlan commented Mar 5, 2014

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

@mdickinson
Copy link
Member

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

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
easy interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

5 participants