j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Thu, Jun 27, 2019 at 12:46:58AM +1000, Chris Angelico wrote:
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.
I'm not convinced that this is going to change under the proposal. Since neither f nor s already exist, they cannot overload assignment. Unless something in Nate's proposal is quite different from earlier concrete proposals, I don't think this is a slam-dunk criticism. I think that it is a problem is theory but not in practice.
The only risk here is if your refactoring does something silly, such as reusing a variable which overrides assignment:
# Earlier: f = something_that_overloads_assignment() # Later on, refactor and re-use f: f = frob(x) # calls overloaded assignment s = f.spam # And then go back to using f process(f) # Oops, shoot yourself in the foot
But the loading and pointing of the gun happened earlier, when you re-used an existing variable, not because of assignment overloading.
As further evidence that this is not a problem in practice, I give you C++ as a data point. C++ is criticised on many, many grounds, e.g.:
but it's quite hard (at least for me) to find any serious criticism of specifically assignment overloading. See for example:
If anyone wants to so their own searches, please let us know if you find any criticism grounded in actual experience with assignment overloading rather than theoretical fears.
The closest to a practical criticism I have found is this one:
but you'll notice that in this case Ruby's behaviour is exactly the same as Python's, and it involved assignment to an attribute.