Operator precedence problem

[Jon Ribbens]

On 2016-06-06, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
><jon+usenet at unequivocal.co.uk> wrote:
>> On 2016-06-06, Chris Angelico <rosuav at gmail.com> wrote:
>>> In that case, please never insult the intelligence of your future
>>> readers by including any of these parentheses:
>>>
>>> x = 1 + (2 * 3)
>>
>> I'm not sure what your point is. Yes, obviously you can take anything
>> to ridiculous extremes - that's why I said "sensible".
>
> Earlier in this thread, it was suggested that parens always be used,
> even for this kind of example.

Ok, but it wasn't me that said that, and I don't agree with it.

>>> value = 77 if (x % 2) else (70*7)
>>
>> I'm not convinced that one isn't actually a good idea. It does seem
>> to aid the readability (especially if you space '70 * 7' properly).
>> If the expressions were any more complex then it would be even more
>> likely to be a good idea.
>
> Hmm, I still think not. But if you want the parens, at least
> acknowledge that they're not to enforce/remind of operator precedence.

That depends on your point of view. I suppose the above without
parentheses could theoretically be taken to mean:
 
  value = (77 if (x % 2) else 70) * 7

although I would agree that people would be unlikely to assume that
was the meaning so they are not required under that heading.

>> I can't tell now if you're agreeing with me or disagreeing, because
>> you started out sounding like you were disagreeing but then provided
>> an example that helps prove my point.
>
> My point is that if you're not sure, you grab interactive Python and
> give it a quick whirl. Usually easier AND quicker than the
> alternatives.

It's never easier and quicker than the meaning of the code simply
being obvious by looking at it, which is the point.