This is the example I was talking about specifically: https://github.com/natelust/CloakingVarWriteup/blob/master/examples.py#L76. There are other possibilities as well, I would be happy to explain my Ideas directly, I am not sure exactly everything Yanghao is saying as I have not been able to follow it very closely. On Wed, Jun 26, 2019 at 5:20 PM Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Jun 27, 2019 at 7:11 AM Yanghao Hua <yanghao.py@gmail.com> wrote:
On Wed, Jun 26, 2019 at 11:00 PM Chris Angelico <rosuav@gmail.com>
wrote:
On Thu, Jun 27, 2019 at 6:50 AM Yanghao Hua <yanghao.py@gmail.com>
wrote:
On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico <rosuav@gmail.com>
wrote:
Let's suppose that frob() returns something that has a __getself__ method. Will f1 trigger its call? Will f2? If the answer is "yes"
to
both, then when ISN'T getself called? If the answer is "no" to both,
What's the problem for the "yes" case? If you define such an object of course __get/setself__() is always called, and f1() is still equal to f2().
Then in what circumstances will getself NOT be called? What is the point of having an object, if literally every reference to it will result in something else being used? The moment you try to return this object anywhere or do literally anything with it, it will devolve to the result of getself, and the original object is gone.
No, it won't -- getself() will/can return self, setself(self, other) will type-checking other and re-interpret them into integers, and do the magic (e.g. signal.next = integer). I implemented exactly the same thing using signal[:] overriding get/setitem(). I mean, how to use it is up to the user, there are endless possibilities. You can choose to return self, or something entirely different, the point is you now have control over "=" operator as you can for the other operators.
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.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/ZBWKD4... Code of Conduct: http://python.org/psf/codeofconduct/
-- Nate Lust, PhD. Astrophysics Dept. Princeton University