
For some reason I haven't received the original email from Daniel. On Thu, Aug 01, 2019 at 04:10:24PM -0400, Calvin Spealman wrote:
I think they actually read like they would mean slightly different things, which would make them existing as aliases confusing.
I agree with Calvin. To me, "if no val" suggests that val is missing or undefined, not false. Further comments to Daniel's suggestion below.
I read `if not val` as "If val isn't true" but i would read `if no val` as "if val does not exist"
On Thu, Aug 1, 2019 at 4:07 PM Daniel Okey-Okoro <danielokeyokoro@gmail.com> wrote:
I think that adding a `no` keyword as an alias for `not` would make for more readable, simple, pythonic code.
If "no" and "not" do the same thing, then one of them is redundant. In general, Python doesn't include multiple aliases for keywords even when we could: None, Nothing, Emptiness, Void, Null, Nil else, elsewise, otherwise, contrariwise Even if we think that another keyword would be better, we just have to learn to live with the one we have. Adding "no" as a keyword would break people's code if they use "no" as a variable, and we don't do that lightly. If "no" and "not" do different things, then they are too similar and it would be a recipe for confusion.
I think this PEP is a work-around for an underlying subtle issue with how the `not` operator is used.
It has two use-cases:
1. as a NOT gate for producing opposite boolean values
``` opposite = not regular ```
2. as a sort of ".is_falsy()" checker; when used with an if statement.
That's one use-case for ``not``, which you may choose to combine with an if-statement, or a while-loop, or any other operation you choose. I trust you wouldn't say that ``not`` has *three* use-cases, because we could combine it with ``print`` to print the words "True" or "False"? The ``not`` operator always does precisely the same thing: it flips the sense of any truthy/falsey object, normalising the result to True or False (the canonical boolean values): truthy values (including True) -> False falsey values (including False) -> True
This PEP would make the difference between the two usecases explicit.
It wouldn't, because you could write: flag = no another_flag flag = not another_flag if no flag: ... if not flag: ... while no expression: ... while not expression: ... and either they do exactly the same thing, or they will do something different and nobody but you will remember which one is which :-) -- Steven