On Sun, Feb 23, 2014 at 1:25 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
it's a fundamentally bad idea to blur that distinction: you should be able to tell *at a glance* whether an operation is mutating an existing object or creating a new one...
Compare:
seq = get_data() seq.sort()
seq = sorted(get_data())
Now, compare that with the proposed syntax as applied to the first operation:
seq = []->extend(get_data())->sort()
That *looks* like it should be a data transformation pipeline, but it's not - each step in the chain is mutating the original object, rather than creating a new one. That's a critical *problem* with the idea, not a desirable feature.
Except that it doesn't. The idea of using a different operator is that it should clearly be mutating the original object. It really IS obvious, at a glance, that it's going to be returning the existing object, because that operator means it will always be. I believe that naming things that don't matter is a bad idea. We don't write code like this: five = 5 two = 2 print("ten is",five*two) because the intermediate values are completely insignificant. It's much better to leave them unnamed. (Okay, they're trivial here, but suppose those were function calls.) In a GTK-based layout, you'll end up creating a whole lot of invisible widgets whose sole purpose is to control the layout of other widgets. In a complex window, you might easily have dozens of those. (Same happens in Tkinter, from what I gather, but I haven't much looked into that.) Naming those widgets doesn't improve readability - in fact, it damages it, because you're left wondering which insignificant box is which. Leaving them unnamed and just part of a single expression emphasizes their insignificance. ChrisA