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.:
http://cshandley.co.uk/CppConsideredHarmful.html
but it's quite hard (at least for me) to find any serious criticism of
specifically assignment overloading. See for example:
https://duckduckgo.com/?q=assignment+overloading+considered+harmful
https://duckduckgo.com/?q=assignment+overloading+criticism
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:
http://www.finagle.org/blog/ruby-gotcha-chained-assignment
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.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/UORM5V5GRNN6RC62G7SJLWUXVP557MUD/
Code of Conduct: http://python.org/psf/codeofconduct/
