[Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
Steven D'Aprano
steve at pearwood.info
Mon Nov 14 06:16:27 EST 2016
- Previous message (by thread): [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
- Next message (by thread): [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote:
[...]
> >> A good syntax example:
> >>
> >> a = sum (a, c)
There is a reason why mathematicians and accountants use symbols as a
compact notation for common functions, instead of purely functional
notation.
Here is a real-world example, the formula for compound interest:
A = P*(1+r/100)**n
Compare that to:
A = mul(P, pow(sum(1, div(r, 100)), n))
Even Reverse Polish Notation is easier to read than that series of
functions:
P 1 r 100 / + n ** *
Don't misunderstand me, functions are important, and over-use of cryptic
symbols that are only meaningful to an expert will hurt readability and
maintainability of code. But people have needed to do arithmetic for
over six thousand years, and there is no good substitute for compact
operators for basic operations.
[...]
> It is kind of clear from the context, that I am speaking of syntax and
> not how things are working under the hood, or?
> If a compiler cannot optimize "a = a + 1" into an in-place operation,
> that is misfortune.
That's not how Python works. Or at least, not without an extremely
powerful and smart compiler, like PyPy.
In Python, integers (and floats) are immutable objects. They have to be
immutable, otherwise you would have things like this:
x = 1
y = x
x = x + 1 # changes the object 1 in place
print(y*10) # expect 10, but get 20
That's how lists work, because they are mutable:
py> x = [1]
py> y = x
py> x[0] = x[0] + 1
py> print(y[0]*10) # expect 1*10 = 10
20
A "sufficiently smart" compiler can work around this, as PyPy does under
some circumstances, but you shouldn't expect this optimization to be
simple.
[...]
> A better option would be to support unary operators so the user
> can write directly without assignment:
>
> inc (a, 1)
>
> Would mean in-place increment "a" with 1
That is impossible with Python's executation model, in particular the
"pass by object sharing" calling convention. I expect that this would
require some extremely big changes to the way the compiler works,
possibly a complete re-design, in order to allow pass by reference
semantics.
The biggest problem is that even if the compiler could choose between
calling conventions, it would have to make that decision at runtime. It
won't know until runtime that inc() requires pass by reference. That
would make function calls even slower than they are now.
--
Steve
- Previous message (by thread): [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
- Next message (by thread): [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Python-ideas
mailing list