Partly it's the layout, but mathematically speaking the two should be equal.
(a*b)/c should equal a*(b/c) The fact that they're not is surprising, because python 2 so seamlessly supports big integers in a mathematically correct way. I consider such surprising behavior to be abstraction leak, which is probably why it has been fixed in python 3. -= m =- On Friday, August 26, 2016 at 12:54:02 AM UTC-7, Erik wrote: > On 26/08/16 08:14, mlz wrote: > > > > I was being facetious, but behind it is a serious point. Neither the APL > > nor the J languages use precedence even though their inventor, Ken Iverson, > > was a mathematician. > > > > That was to support functional programming dating back to the 1970's. > > Precedence is not the issue here anyway. Both '*' and '/' have the same > precedence. The two operations in your expressions have to be evaluated > in SOME order - either left-to-right or right-to-left. > > > The issue is twofold: > > Firstly, the compound assignments will always evaluate their RHS before > performing the assignment - this is not the same as operator precedence > - they have to, else what does Python pass to the function that knows > what the compound assignment means for that type (e.g. sequences may be > extended for '*=')? So for compound assignments there is always > effectively an implicit set of parentheses around the RHS compared to > the expression without the assignment operator (if you think of the > compound assignment as being a _part_ of the overall expression). > > Secondly, the way you have chosen to layout your code has fooled your > brain into thinking that the division is performed before the > multiplication. Python doesn't care that you jammed the sub-expression > together with no whitespace ;) > > E. -- https://mail.python.org/mailman/listinfo/python-list
