Odd truth result with in and ==

Chris Angelico rosuav at gmail.com
Wed Nov 21 16:40:51 EST 2018


On Thu, Nov 22, 2018 at 8:22 AM Python <python at bladeshadow.org> wrote:
>
> On Thu, Nov 22, 2018 at 07:54:06AM +1100, Chris Angelico wrote:
> > >   if item in list == item_should_be_in_list():
> > >     # "good" state, i.e. is true if item is in list and should be, or isn't and shouldn't.
> > >     ...
> >
> > If I saw this in _any_ language, I would want it to be parenthesized
> > for clarity. This kind of comparison is extremely unusual, and
> > benefits from not making assumptions about how comparisons chain. And
> > parenthesized, it will work the same way in any language.
>
> I tend to agree in practice, but the idealist in me wants to say
> that's poppycock--every language has rules for expression evaluation
> and operator precedence, and that is all the clarity that should be
> required.  If you don't know them, parens or not, you're going to get
> it wrong some of the time, and writing superfluous code to compensate
> for other people's inadequacies is irksome.

Not every language does, just most languages. And they aren't all the
same. Remember: Code should be written first and foremost for other
humans to read, and only secondarily for a machine to read. We use
descriptive variable names, spaces around operators, etc, etc, etc,
not because the Python interpreter needs the information, but because
the humans need it.

If you see code like you quoted, you can follow a set of algorithmic
rules to figure out how the interpreter will parse it. But you can't
follow those rules to determine how the original programmer INTENDED
it to be parsed. Can you assume that the code is bug-free? I usually
can't, whether it's my code or someone else's.

ChrisA



More information about the Python-list mailing list