Chris,
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
examples.py 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 <ros...@gmail.com> wrote:
> On Thu, Jun 27, 2019 at 6:50 AM Yanghao Hua <yanghao...@gmail.com> wrote:
> >
> > On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico <ros...@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.
>
> ChrisA
> _______________________________________________
> 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/DXRITYQA3MY7P6V3FYGE7ZPR53EHWHPV/
> 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/JZY5T37LKOB74QVJ4XWZN62E5SEXNMW6/
Code of Conduct: http://python.org/psf/codeofconduct/
