j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 26 Jun 2019, at 16:46, Chris Angelico firstname.lastname@example.org wrote:
On Thu, Jun 27, 2019 at 12:37 AM Anders Hovmöller email@example.com wrote:
On 26 Jun 2019, at 14:28, Rhodri James firstname.lastname@example.org wrote:
On 26/06/2019 08:34, Yanghao Hua wrote: I find the objection reasoning very strange as none of the default behavior changed, and yet if you use this feature you do need to worry about the object behavior regarding assignment, this is true for descriptors and all other magics.
The problem is not the default behaviour. The problem is that the average reader of your code cannot know that something that appears to be an ordinary assignment has been redefined elsewhere to be something entirely herring. Your code stops being understandable to other people.
I 100% agree that this proposal is a bad idea. But I do have to play Devils advocate here.
The the-code-is-understandable-at-face-value ship has already sailed. + doesn't mean add, it means calling a dunder function that can do anything. Foo.bar = 1 doesn't mean set bar to 1 but calling a dunder method. In python code basically can't be understood at face value.
There are many things that can be implemented with dunders, yes, but in Python, I would expect these two functions to behave identically:
def f1(x): return frob(x).spam
def f2(x): f = frob(x) s = f.spam return s
This correlation is critical to sane refactoring. You should be able to transform f1 into f2, and then insert print calls to see what 'f' and 's' are, without affecting the behaviour of the function. The proposed magic would change and completely break this; and as such, it violates programmer expectations across many languages regarding refactoring.
I'm out of the game for many years but isn't that potentially extremely different in C++ for example?