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 11:39:04PM +1000, Chris Angelico wrote:
On Thu, Jun 27, 2019 at 11:11 PM Steven D'Aprano email@example.com wrote:
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.
That would be true if the proposal were only for __setself__, but the __getself__ part makes things more complicated. I'm not 100% sure because I don't fully understand the proposal, but if the object returned by frob(x) has a __getself__ method, I think it would be called in f2 but NOT in f1 (because referencing the name "f" triggers the get, whereas simply chaining ".spam" onto the end of the function call doesn't).
Without getting into any debate over whether we need both __getself__ and __setself__, I assume that if __getself__ is called at all, it is called consistently. Any lookup of the object ought to call it, not just a bare name.
If Nate's proposal says differently, I would hope it is an oversight rather than an intended feature.