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