[issue26847] filter docs unclear wording

Luke added the comment: 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.

[issue26847] filter docs unclear wording

Georg Brandl added the comment: 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

[issue26847] filter docs unclear wording

Luke added the comment: 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.

[issue26847] filter docs unclear wording

Josh Rosenberg added the comment: That's why lower case "false" is used, not "False"; the former is the loose definition, the latter is the strict singleton. -- ___ Python tracker

[issue26847] filter docs unclear wording

Josh Rosenberg added the comment: "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,

[issue26847] filter docs unclear wording

New submission from Luke: 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