[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Operator precedence problem

On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
<jon+usenet at> wrote:
> On 2016-06-06, Chris Angelico <rosuav at> wrote:
>> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
>><jon+usenet at> 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