There are a lot of messages for me to catch up on from today, but I am heading home from work, and your most recent one is the easiest to address quickly.

I want to start out by saying I agree with many of the objections and concerns raised here, and there were some I had not thought about. This is why I put the proposal out, to learn more and perhaps make a stronger proposal (I like the idea raised last night of denoting these variables with a keyword to denote they are special and should be treated as such).

Yanhao, I do not think you are doing this proposal any good. I appreciate you trying to go to bat for it, but there are many good concerns here that would be good to hear out and address rather than trying to dismiss them.

To your last message Chris, I just wanted to point out one way I envision this may be used used (Although it is still a bit of a toy). In my longer file I have a history variable that tracks all the values that were bound to the name (using __setself__) in a history list. __getself__ would then always return the most recently set value when loaded. I introduced a "built in" called getcloaked what would allow fetching the actual cloaking variable such that it could be used. In this case that would be something like getcloaked('var').rollback_history(2) to move back to a previous assignment. This could potentially be used in say a debugger, or try except or the like. As you say this would only be good from within a single scope, unless the return statement of the function was: return getcloaked('var') (or conversely a function was called like foo(getcloaked('var") to pass it into scope).

I do think that this proposal needs work (or possibly thrown out all together if it could not be refined), and all the ideas and questions were exactly what I was hoping for, as there is more that others will be able to see than I am alone.

On Wed, Jun 26, 2019 at 5:04 PM Chris Angelico <> wrote:
On Thu, Jun 27, 2019 at 6:50 AM Yanghao Hua <> wrote:
> On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico <> 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.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Nate Lust, PhD.
Astrophysics Dept.
Princeton University