> > Simply put:
> >
> > a += 1 IS NOT ATOMIC!
> >
> If that's the case, then why do we need augemented assignments
> at all ?
>
> (I understood the atomicness being the main argument for
> introducing augmented assigns.)
Huh? Where did you get that idea? Can you point to a message where
this was indicated?
The reason for introducing it is that it's been the single-most
requested feature ever since Python's inception. I think the reason
it's been requested so much is that it's a waste of typing skills as
well as (and more importantly) unnecessary extra effort to deduce
what's going on in code like
a.b.f().x[i] = a.b.f().x[i] + 1
Another important reason is that in cases like
a[long_and_expensive_call()] = a[long_and_expensive_call()] + 1
you want to avoid doing the long_and_expensive_call() twice.
Introducing a temp variable reduces the readability of the code.
Note that my proposed semantics guarantee that in
a[long_and_expensive_call()] += 1
the index is computed only once -- but this is not the same as
atomicity (which has to do with other threads, signal handlers and
similar asynchronous things).
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4