Operator precedence problem

[Chris Angelico]

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:
>> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
>><jon+usenet at unequivocal.co.uk> wrote:
>>>>> You should put brackets around expressions when it's at all unclear
>>>>> what the meaning is. You could think of them a bit like "active
>>>>> comments" I suppose.
>>>>
>>>> Your code should keep noise to the minimum.
>>>
>>> Sensible and beneficial comments aren't "noise".
>>
>> 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.

>> 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.

>> And if your readers have to figure out what 3**3**3 is interpreted as,
>> there should be an interactive interpreter around. Or here - try
>> something cute:
>>
>>>>> 2**2**-1
>
> 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.

ChrisA