indeed -- and that is pretty darn baked in to Python, so I don't think it's going to change.
30 years of history beats out 8 years since the last discussion of this. 😉
Except this convention doesn't hold for dict.setvalue (which I did misspell, sorry), or for dict.pop.
I don't know what you mean by setvalue(), but I'm assuming you meant setdefault(). If that's true, then the guideline isn't "all mutating methods must return None", it's "unless the method is specifically designed to have a return value based on the purpose of the method, the method should return None".
Both these methods fundamentally mutate the collection, but they also return a value (which could be retrieved by a non-mutating method), that somewhat pertains to the operation performed.
Both pop() and setdefault() are meant to return something, they just also happen to mutate things. You're wanting the reverse and that isn't how Python has chosen to go.
Same with people who bring up wanting a fluent API where 'self' is always returned. It's a very specific decision that for methods that do nothing but mutation they return None to signify that you're not getting back a new object, but something that mutated in-place. This is why list.sort(), for instance, returns None; you are not getting a new copy of the list sorted, you actually changed the original object which you should have named with a variable. That way you have to access the object by the name you already gave it as a reminder its the same object.
Plus Python isn't big on the crazy one-lineers where you might want to do an inline call of add() to simply save yourself one line of code. Explicit is better than implicit, and that can mean needing to simply do something in two lines instead of one.