On Thu, Jun 27, 2019 at 7:11 AM Yanghao Hua firstname.lastname@example.org wrote: >
On Wed, Jun 26, 2019 at 11:00 PM Chris Angelico email@example.com wrote: >
On Thu, Jun 27, 2019 at 6:50 AM Yanghao Hua firstname.lastname@example.org wrote: >
On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico email@example.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.