<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 14, 2016 at 1:21 PM, Mikhail V <span dir="ltr"><<a href="mailto:mikhailwas@gmail.com" target="_blank">mikhailwas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 14 November 2016 at 12:16, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
> On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote:<br>
><br>
> [...]<br>
>> >> A good syntax example:<br>
>> >><br>
>> >> a = sum (a, c)<br>
><br>
> There is a reason why mathematicians and accountants use symbols as a<br>
> compact notation for common functions, instead of purely functional<br>
> notation.<br>
><br>
> Here is a real-world example, the formula for compound interest:<br>
><br>
> A = P*(1+r/100)**n<br>
><br>
> Compare that to:<br>
><br>
> A = mul(P, pow(sum(1, div(r, 100)), n))<br>
><br>
> Even Reverse Polish Notation is easier to read than that series of<br>
> functions:<br>
><br>
> P 1 r 100 / + n ** *<br>
><br>
><br>
> Don't misunderstand me, functions are important, and over-use of cryptic<br>
> symbols that are only meaningful to an expert will hurt readability and<br>
> maintainability of code. But people have needed to do arithmetic for<br>
> over six thousand years, and there is no good substitute for compact<br>
> operators for basic operations.<br>
<br>
</span>I agree. Actually I meant that both are good examples.<br>
In some cases I still find function-style better, so this:<br>
<br>
A = P*(1+r/100)**n<br>
<br>
I would tend to write it like:<br>
<br>
A = P * pow((1 + r/100) , n)<br>
<br>
For me it is slightly more readable, since ** already makes the<br>
equation inconsistent.<br><br></blockquote><div><br></div><div>Okay, then make a proposal to get the operators included as built-ins.  Once you have gotten that approved, then we can start talking about which syntax is better.  But the idea that people should import a module to do basic mathematical operations is a non-starter.  <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Most of problems with function-style equations come from limitations<br>
of representation<br>
so for Courier font for examples the brackets are too small and makes<br>
it hard to read.<br>
With good font and rendering there no such problems. Some equation editors<br>
allow even different sized brackets - the outer extend more and more<br>
when I add nested equations, so it looks way better.<br>
<div><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>You shouldn't be using a variable-width font for coding anyway.  That is going to cause all sorts of problems (indentation not matching up, for example).  You should use a fixed-width font.<br><br></div><div>But if brackets are a problem, I don't see how using more brackets is a solution (which is the case with function calls).  On the contrary, I would think you would want to minimize the number of brackets.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5">
<br>
> [...]<br>
>> It is kind of clear from the context, that I am speaking of syntax and<br>
>> not how things are working under the hood, or?<br>
>> If a compiler cannot optimize "a = a + 1" into an in-place operation,<br>
>> that is misfortune.<br>
><br>
> That's not how Python works. Or at least, not without an extremely<br>
> powerful and smart compiler, like PyPy.<br>
><br>
> In Python, integers (and floats) are immutable objects. They have to be<br>
> immutable, otherwise you would have things like this:<br>
><br>
> x = 1<br>
> y = x<br>
> x = x + 1  # changes the object 1 in place<br>
> print(y*10)  # expect 10, but get 20<br>
><br>
> That's how lists work, because they are mutable:<br>
><br>
> py> x = [1]<br>
> py> y = x<br>
> py> x[0] = x[0] + 1<br>
> py> print(y[0]*10)  # expect 1*10 = 10<br>
> 20<br>
><br>
><br>
> A "sufficiently smart" compiler can work around this, as PyPy does under<br>
> some circumstances, but you shouldn't expect this optimization to be<br>
> simple.<br>
><br>
> [...]<br>
>> A better option would be to support unary operators so the user<br>
>> can write directly without assignment:<br>
>><br>
>> inc (a, 1)<br>
>><br>
>> Would mean in-place increment "a" with 1<br>
><br>
> That is impossible with Python's executation model, in particular the<br>
> "pass by object sharing" calling convention. I expect that this would<br>
> require some extremely big changes to the way the compiler works,<br>
> possibly a complete re-design, in order to allow pass by reference<br>
> semantics.<br>
<br>
</div></div>Thanks a lot for a great explanation!<br>
So for current Python behavior, writing<br>
<span class="gmail-"><br>
x = x + 1<br>
<br>
</span>and<br>
<br>
x += 1<br>
<br>
Would mean the same in runtime? Namely creates a copy and assigns<br>
the value  x+1  to x. Or there is still some overhead at parsing stage?<br>
Then however I see even less sense in using such a shortcut,<br>
it would be good to dismiss this notation, since it makes hard<br>
to read the code.<br></blockquote><div><br></div><div>No, that is only the case for immutable types like floats.  For mutable types like lists then <br><br></div><div>x = x + y<br></div><div><br></div><div>and<br><br></div><div>x += y <br><br></div><div>Are not the same thing.  The first makes a new object, while the second does an in-place operation.  Sometimes you want a new object, sometimes you don't.  Having both versions allows you to control that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As for Numpy, it uses anyway its own approaches, so<br>
in-place should use own syntax, e.g. like numpy.sum(x_, a) to<br>
do it in-place.<br>
<span class="gmail-HOEnZb"></span><br></blockquote></div><br>First, there is no "_" suffix for variables that numpy could use.  The syntax you are suggesting isn't possible without a major change to the basic python grammar and interpreter.  <br><br>Second, again, "sum(x, a)" does not add "x" and "a". <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Third, again, why?  You still haven't given any reason we should prefer this syntax. If this is just your personal preference, please say that.  But if you expect people to add a bunch of new built-ins, implement your new suffix syntax, and implement your massive changes to how python operations and function calls work, then you are going to need something more than personal preference.<br><br></div><div class="gmail_extra"><br></div></div>