On Sun, Nov 17, 2019 at 12:43:55AM -0800, Neil Girdhar wrote:
> Some people find this legal syntax confusing:
>
> A in B < C
>
> (It means A in B and B < C.)
>
> I feel like most code reviews would not allow this kind of code to be
> checked in, at least without a comment explaining what the code does. What
> are the motivating reasons for allowing this syntax? Is there any
> idiomatic code that uses it?
Programming languages permit lots of unidiomatic code that is allowed
without there being a specific motivating reason for allowing it. I
doubt that any of us would ask for a motivating reason to allow this:
print(print(value) or print(another_value) or third_value)
or expect there to be idiomatic code that includes this:
if True is (((value is True) is (True is True) is True) is True)
just because the language allows it. It is a never ending task to try to
prevent any unidiomatic, ugly code at the language itself, especially
since what counts as "ugly" is often so subjective.
Generally, we need a better reason to prohibit something than just
personal preference "I don't think you should write that code". Not all
code is, or needs to be, best practice. I don't recall if I've ever
chained operators similar to the example you have given, but I've
written lots of code that *I* don't approve of, because if I'm
experimenting in the REPL who cares if I write something idiomatic or
not? It works, it does what I want, it doesn't matter if it is ugly or
wouldn't survive a code review.
What error message could you raise that wouldn't come across as sounding
like HAL from 2001 scolding the coder? "I'm sorry Dave, I'm afraid I
can't allow you to do that."
Better to leave this to linters, style guides, code reviews and the
individual good taste of the coder.
> If not, I suggest dividing the comparison operators into two groups:
[...]
Still allowed:
a > b < c
a <= b >= c != a
a in b is c is not a
which are equally as hideous as your motivating example. This is adding
a significant semantic complication to the language, without actually
preventing what you set out to prevent:
Aim: prevent the coder from abusing chained comparisons.
Result: now there are two kinds of comparison operators which
have nothing in common except an arbitrary division, but the
coder can still abuse chained comparisons.
> For example,
> you might write your own comparison operator and then want to see if it's
> working:
>
> A < B is None
>
> returns false if B is not None even if A < B returns None.
"Suspiciously specific example." Did you do this?
Ironically, this similarly awful code would be allowed under your "two
groups" proposal:
a in b is None
since the `in` operator is in the same group as the `is` operator.
So would these:
a < b == None
a < b == -1 # using -1 instead of None as sentinel
> Also, in my opinion, the existence is a deterrent to Python
o_O
Do you have evidence of actual, real people saying words to the effect
of this?
"I was going to use Python, but when I saw that you can abuse
chained comparisons to write ugly code, I decided against it."
> and takes away from Python's beauty as a language.
*shrug*
I don't know, I think that the cure in this case is worse than the
disease. Yes, there are some ugly abuses of chained comparisons, but
dividing comparison operators into two arbitrary groups seems even
uglier to me.
None is not a > b
0 != a > b
I can't say that the language is improved by prohibiting the first but
allowing the second.
I think that the status quo has the beauty of simplicity:
a <op1> b <op2> c
=> "a <op1> b and b <op2> c" for op1, op2 both comparison operators
while your proposal has the ugliness of (unnecessary?) complexity:
a <op1> b <op2> c
=> "a <op1> b and b <op2> c" for op1, op2 both "group 1 comparison
operators", or op1, op2 both "group 2 comparison operators",
or a syntax error for op1, op2 in different groups.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/O6KLZBV3TWYMBIKGBIUSNIQI4SSFT45Y/
Code of Conduct: http://python.org/psf/codeofconduct/
