All, Thanks for the feedback that everyone has provided. My time will be in short supply in the near term, and so I am going to focus on taking all the input that people have provided and if possible flesh out a stronger proposal. I figured this would also slow the flood of emails on this thread that people are receiving. I am still more than happy to discuss this with anyone who wants to talk about this, either on this thread, or direct mail if anyone wants to drop me a line. Over the next day or so I will try and address any outstanding questions that people have raised on this thread that are not related to work that I need to go off and do, or tests that need run.
Thank you all again for the input, and helping to ask questions that are hard to see from the perspective I have.
On Fri, Jun 28, 2019 at 4:04 AM Stephen J. Turnbull firstname.lastname@example.org wrote:
Andrew Barnert writes:
On Jun 26, 2019, at 21:45, Stephen J. Turnbull email@example.com wrote: >
Chris Angelico writes:
Then I completely don't understand getself. Can you give an example of how it would be used? So far, it just seems like an utter total mess.
It's possible that __getself__ would be implemented "halfway". That is, if __getself__ is present, it is invoked, and performs side effects (a simple example would be an access counter/logger for the object). Then the compiler loads that object, discarding any return value of the method. I think this is the semantics that the proponents are thinking of.
The compiler has to load the object before calling __getself__, not after, or it has nothing to call __getself__ on, right?
Correct. I should have said "leaves the object alone rather than substituting the value of the method".
Anyway, I don’t think this really avoids most of the problems.
Agreed. I just thought that it was worth clarifying that __getself__ could be entirely about side effects by definition.
And I think everything else is an inherent consequence of trying to answer “I want to hook this operation on variables”
Yeah, I really don't understand why this is desirable in Python, but if it is,
“here’s an hook on values instead”
is not the way to do it. All roads lead to "We don't need a proof of concept implementation, we need a proof of utility application."
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/VIQ522... Code of Conduct: http://python.org/psf/codeofconduct/
-- Nate Lust, PhD. Astrophysics Dept. Princeton University