On 15 November 2016 at 00:34, Paul Moore <p.f.mo...@gmail.com> wrote: > On 14 November 2016 at 22:13, Mikhail V <mikhail...@gmail.com> wrote: >>> we don't want A = A + 1 to be the same as A += 1 " >> >> This sounds quite frustrating for me, what else could this be but A += 1? >> Would I want a copy with same name? How that will make sense? > >>>> A = [1,2,3] >>>> B = A >>>> A = A + [1] >>>> A > [1, 2, 3, 1] >>>> B > [1, 2, 3] >>>> A = [1,2,3] >>>> B = A >>>> A += [1] >>>> A > [1, 2, 3, 1] >>>> B > [1, 2, 3, 1] > > For a mutable class, A = A + something is fundamentally different from > A += something. > > Before proposing fundamental changes to Python's semantics, please > make sure that you at least understand those semantics first, and > explain why your proposal is justified. There are a lot of people on > this list, and the cumulative time spent reading your posts is > therefore quite significant. You owe it to all those readers to ensure > that your proposals are at least feasible *in the context of the > Python language*. > > Paul
Ok I am calmed down already. But how do you jump to lists already? I started an example with integers. I just want to increment an integer and I don't want to see any += in my code, it strains me. And that is exact reason I hate C syntax. Then Todd started about Numpy arrays. Ok, I just commented what I find for clearer syntax with array increment. And now lists, mutable classes... I don't use classes in my programs. I could propose something but how, if we mix everything in one big pile? Then my proposal is to make typed variables first, so I could at least consider use cases. Mikhail _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
