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 < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Andrew Barnert writes: > > On Jun 26, 2019, at 21:45, Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> 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 -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VIQ52275FZIKMO4RVY4S6DW4IKTMDFRU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Nate Lust, PhD. Astrophysics Dept. Princeton University
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BQ2MOKNQWSE2UFT7CI6DRLRXZH6C3GQ3/ Code of Conduct: http://python.org/psf/codeofconduct/
