PEP: add a `no` keyword as an alias for `not`
I think that adding a `no` keyword as an alias for `not` would make for more readable, simple, pythonic code. Take the below: ``` if not val: do_thing_because_value_is_falsy() ``` could be (is actually understood as): ``` if no val: do_thing_because_value_is_falsy() ``` 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. like the first example. This PEP would make the difference between the two usecases explicit. Thoughts? Best Intentions, Daniel Okey-Okoro.
I think they actually read like they would mean slightly different things, which would make them existing as aliases confusing. 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.
Take the below:
``` if not val: do_thing_because_value_is_falsy() ```
could be (is actually understood as):
``` if no val: do_thing_because_value_is_falsy() ```
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.
like the first example.
This PEP would make the difference between the two usecases explicit.
Thoughts?
Best Intentions, Daniel Okey-Okoro. -- https://mail.python.org/mailman/listinfo/python-list
-- CALVIN SPEALMAN SENIOR QUALITY ENGINEER cspealma@redhat.com M: +1.336.210.5107 [image: https://red.ht/sig] <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
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
On Fri, Aug 2, 2019 at 6:09 AM 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.
The bar for creating new keywords is extremely high. Simply making your code slightly more like English is not a strong enough justification for breaking any code that uses "no" in any other way. ChrisA
On 08/01/2019 01:06 PM, Daniel Okey-Okoro wrote:
[an idea]
Two things: 1) please do not cross-post. 2) a PEP is a very particular thing* -- please do not say you have one unless you do. ;) -- ~Ethan~ * https://www.python.org/dev/peps/pep-0001/
I did a quick scan of the source code I have checkout. I see "no" as a variable in Python, PyPy, GitPython and setuptools. Adding "no" as a keyword will break at least those projects. Barry Here are the details: Python3/Lib/distutils/tests/test_util.py 249 no = ('n', 'no', 'f', 'false', 'off', '0', 'Off', 'No', 'N') Python3/Lib/test/test_descr.py 1752 no = NoWeak() Python3/Lib/pydoc.py 160 no = [] Python3/Lib/tkinter/messagebox.py 51 NO = "no" setuptools/dist.py 586 no = self.negative_opt.copy() GitPython/git/test/performance/test_commit.py 38 no = 0 pypy/rpython/translator/goal/bpnn.py 53 self.no = no pypy/rpython/rtyper/lltypesystem/ll2ctypes.py 809 no = _opaque_objs_seen[container] 811 no = len(_opaque_objs) pypy/rpython/jit/metainterp/test/test_warmspot.py 591 self.no = no 593 no = self.no 595 if no == 0: 597 if no == 1: 600 if no == 3: pypy/rpython/jit/tl/tinyframe/tinyframe.py 102 no = int(arg[1:]) pypy/rpython/jit/backend/test/test_random.py 177 no = len(self.descr_counters) 201 no = len(TYPE_NAMES) pypy/rpython/jit/backend/zarch/conditions.py 31 NO = ConditionLocation(0xe) # NO overflow pypy/rpython/jit/backend/llsupport/jitframe.py 123 no = 0 pypy/rpython/jit/tool/traceviewer.py 77 self.no = self.counter 206 no = int(m.group(1)) pypy/rpython/tool/jitlogparser/storage.py 81 no = int(comment[len('# bridge out of Guard 0x'):].split(' ', 1)[0], 16) 86 loop.no = no pypy/pypy/module/pypyjit/interp_resop.py 21 no = 0
On 1 Aug 2019, at 21:06, 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.
Take the below:
``` if not val: do_thing_because_value_is_falsy() ```
could be (is actually understood as):
``` if no val: do_thing_because_value_is_falsy() ```
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.
like the first example.
This PEP would make the difference between the two usecases explicit.
Thoughts?
Best Intentions, Daniel Okey-Okoro. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JC6WOB... Code of Conduct: http://python.org/psf/codeofconduct/
participants (6)
-
Barry Scott -
Calvin Spealman -
Chris Angelico -
Daniel Okey-Okoro -
Ethan Furman -
Steven D'Aprano