This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: filter docs unclear wording
Type: enhancement Stage:
Components: Documentation Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, georg.brandl, josh.r, unfamiliarplace
Priority: normal Keywords:

Created on 2016-04-26 03:15 by unfamiliarplace, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg264206 - (view) Author: Luke (unfamiliarplace) Date: 2016-04-26 03:15
The current docs for both filter and itertools.filterfalse use the following wording (emphasis added):

all elements that are false are removed
returns the items that are false
This could be confusing for a new Python programmer, because the actual behaviour is that elements are equality-compared, not identity-compared.

Suggested wording: "are equal to False"

https://docs.python.org/3.5/library/functions.html#filter
https://docs.python.org/3.5/library/itertools.html#itertools.filterfalse
msg264207 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2016-04-26 04:01
"are equal to False" would be wrong though. Any "falsy" value is preserved by filterfalse, and removed by filter. They need not be equal to False (the bool singleton); empty containers (e.g. (), [], {}, "") are all considered false, and behave as such, despite not being equal to False.
msg264208 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2016-04-26 04:02
That's why lower case "false" is used, not "False"; the former is the loose definition, the latter is the strict singleton.
msg264209 - (view) Author: Luke (unfamiliarplace) Date: 2016-04-26 04:22
josh, we're saying the same thing but misunderstanding each other. :)

I realize that they can be empty containers, etc., and that's why I think "equal to False" is appropriate -- because those things *are* equal to False:

>>> [] == False
True
>>> 0 == False
True
etc.

However, they are not identical to False:

>>> [] is False
False
>>> 0 is False
False

And that's why I think the wording "are false" is potentially misleading.

Perhaps there's a better wording than "equal to False" (compares equivalently to False? or simply: are falsey? :p), but anyhow, we're identifying the same behaviour here.
msg264216 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2016-04-26 05:44
You didn't test your examples:

>>> [] == False
False

False is not equal to the "empty value" of any other type than other numeric types.  (This is mostly because of how booleans were originally introduced to Python.)

"is false", on the other hand, is the conventional shorthand for `bool(x) == False`.
msg264275 - (view) Author: Luke (unfamiliarplace) Date: 2016-04-26 13:06
For shame! ... I deserved that callout. :S

My examples should have included the cast to bool, which is indeed not the same as the values' being "equal to False" in themselves...

I didn't realize that "is false" was conventional shorthand for that cast and comparison. Thanks!
History
Date User Action Args
2022-04-11 14:58:30adminsetgithub: 71034
2016-04-26 13:06:41unfamiliarplacesetmessages: + msg264275
2016-04-26 05:44:46georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg264216

resolution: not a bug
2016-04-26 04:22:02unfamiliarplacesetmessages: + msg264209
2016-04-26 04:02:24josh.rsetmessages: + msg264208
2016-04-26 04:01:43josh.rsetnosy: + josh.r
messages: + msg264207
2016-04-26 03:15:40unfamiliarplacecreate