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/
