This is just a matter of understanding the actual semantics of Python, which is not the same as other languages such as C. In Python the "assignment operator" is a way of *binding a value*. So writing:
a = some_expression Is ALWAYS and ONLY binding the value of `some_expression` to the name `a`. The fact that `a` might occur within `some_expression` is irrelevant to these semantics (although it *does* mean that subsequent code won't use `a` to refer to whatever value it used to have. In clear and distinct contrast, "augmented assignment" is a way of calling a method on an object. So writing: a += some_expression Means EXACTLY: a.__iadd__(some_expression) I recognize this can have the same effect if `__iadd__()` is not explicitly defined, and when that is true, it will fall back to using `__add__()` as the implementation. This is described in: https://www.python.org/dev/peps/pep-0203/ To see the difference, e.g.: >>> class Foo: .... def __add__(self, other): .... print("Adding", other) .... return other .... def __iadd__(self, other): .... print("Inplace assignment", other) .... return self .... >>> foo = Foo() >>> foo += 3 Inplace assignment 3 >>> foo + 3 Adding 3 3 >>> foo = foo + 3 Adding 3 >>> foo # I'm bound to an int now 3 On Mon, Nov 14, 2016 at 2:13 PM, Mikhail V <mikhail...@gmail.com> wrote: > On 14 November 2016 at 21:52, Todd <toddr...@gmail.com> wrote: > > >> I can understand you good. But imagine, if Numpy would allow you to > >> simply write: > >> A = A + 1 > >> Which would bring you directly to same internal procedure as A += 1. > >> So it does not currently, why? > > > > > > First, because the language doesn't allow it. > > > > But more fundamentally, sometimes we don't want A = A + 1 to be the same > as > > A += 1. Making a copy is sometimes what you want. Having both versions > > lets you control when you make a copy rather than being forced to always > > make a copy or always not. > > > 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? > > Making a copy is how it works now, ok. But even now there are differences, > eg: > A = B [1:10] > is not a copy but a reference creation operation. So there are > different meanings of =. > > > > >> > >> I never would. Also I think to implement this syntax would be almost > >> trivial, it should > >> just take the A = A part and do the rest as usual. > > > > > > The Python language doesn't allow it. numpy can only work with the > > information provided to it be the language, and the information needed > to do > > that sort of thing is not provided to classes. Nor should it in my > opinion, > > this is one of those fundamental operations that I think absolutely must > be > > consistent. > > > > What you are talking about is an enormous backwards-compatibility > break. It > > is simply not going to happen, it would break every mutable class. > > > > I don't want to break anything, no. I don't have such deep knowledge of all > cases, but that is very interesting how actually it must break > *everything*. Say I > scan through lines and find "= " and then see that on the left is an numpy > array, which already indicates a unusual variable. > And if look on the right side and first argument is again A, cannot I > decide to make an exception and redirect it to A.__add__() or what > must be there. > It does already do an overloading of all these "+=" for numpy. > so what will fundamentally break everything I am not sure. > > > And you still have not provided any reason we should want to do it this > way. > > If let alone numpy for now and take only numeric Python variables, I > find the += syntax > very bad readable. I must literally stop and lean towards the monitor > to decipher > the line. And I am not even telling that you *cannot* do it with all > possible operations: > there are standard math, ORing ,XORing, conditionals, bitshifting etc. > Is not this obvious? > And what other reason apart from readability there can be at all? > Again, how about TOOWTDI principle? some write a = a + 1, some a += 1 ? > It does not add any pleasure for reading code. > > > >> Most of problems with function-style equations come from limitations > >> of representation > >> so for Courier font for examples the brackets are too small and makes > >> it hard to read. > >> With good font and rendering there no such problems. Some equation > editors > >> allow even different sized brackets - the outer extend more and more > >> when I add nested equations, so it looks way better. > > >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. > > No no, I should not use monowidth fonts and nobody ever should. Most > of those "indentation" problems are just though-out, > All you need is IDE with good tabulation support. The readability > difference between monowidth and real fonts > is *huge*. Currently I am forced to use monowidth, since it is VIM's > limitation and it bothers me a lot. > Exception is tables with numbers, but those should not be inputed in > same manner as strings, it is other medium type. > > 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/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
