I addressed some of the concerns you were responding to in the long email I wrote last night. I introduced a change to address this, see previous email for more details.
On Thu, Jun 27, 2019 at 11:11 PM Steven D'Aprano <firstname.lastname@example.org> wrote:
> 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.
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
Does that change your view of it?
Python-ideas mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/TK3EFWG6OHXA2UQ7DF7RLIBPRHQDR77I/
Code of Conduct: http://python.org/psf/codeofconduct/
Nate Lust, PhD.