On Apr 20, 2020, at 08:41, J. Pic <jpic@yourlabs.org> wrote:
Currently, list.append(x) mutates the list and returns None.
Yes, which is consistent with the vast majority of mutating methods in Python. It would be pretty weird to make lst.append(x) return x, while lst.extend(xs) still returns None, not to mention similar methods on other types like set.add.
It would be a little syntactic sugar to return x, for example:
something = mylist.append(Something())
You can already get the same effect with: mylist.append(something := Something()) I think usually this would be more readable (and pythonic) as two lines rather than combined into one: something = Something() mylist.append(something) But “usually” isn’t “always”, and that’s why we have escape hatches like the walrus operator. It’s for exactly this purpose, where a subexpression needs to be bound to a name, but for some reason it can’t or shouldn’t be extracted to a separate assignment statement. And I think this is a lot clearer about what’s getting assigned to something, too. Someone who’s never seen the walrus operator won’t understand it, but at least it’s unlikely they’re going to misunderstand it as something other than what it means. This is especially an issue with methods like list.append. In a lot of other languages, they return self, because the language encourages method chaining for fluid programming (Perl, Ruby), or because list appending is non-mutating (Scala, Haskell), or for bizarre reasons specific to that language (Go), so a lot of people are likely to misunderstand your syntax as meaning that something gets the new value of the list.