Stephen, Thanks for the reply, it is a busy day at work today, so it is going to take me a little bit of time to sit down and really process all you have said. I wanted to drop you a message though and link you to the examples that I mentioned. https://github.com/natelust/CloakingVarWriteup/blob/master/examples.py . If you want to see them in context with the outputs (to save cloning and building my patched python) they can be found at the end of this document: https://github.com/natelust/CloakingVarWriteup/blob/master/writeup.md. A direct link to the interpreter changes that support this can be found here: https://github.com/natelust/cpython/commit/3b3714694b9cd9e2b1b706661765050c363ce35a, in case there is any question on how things are working, or just general interest.
I do appreciate you, and everyone, taking their time to weight in on this, as it is very educational. Once I have a bit of spare brain power, I will fully process what you wrote and may have additional questions. Thank you On Wed, Jun 26, 2019 at 3:12 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > nate lust writes: > > > On first read, that may be surprising, but it extends a behavior > > pattern that already exists for things like properties (and > > generically descriptors) to object instances themselves. > > I don't think that's a correct interpretation. In all cases of > assignment, a name is rebound (in some sense) in a separate namespace. > In the case of an attribute, that namespace us explicit. It *is* the > object, and we know the object's type: the type of objects that have > that attribute. (Circular, do you say? Well, that circularity is the > essence of duck typing.) > > What you want to do is make some object its own namespace, and that > breaks the connection between "bare" names and the implicit namespace > of the module or function that contains it. Your proposal will set > magic loose in the world: it is no longer possible to reason with > confidence about the behavior of objects denoted by bare names > locally. This is action at a distance on *every name in a program*. > > Attribute notation makes action at a distance (ie, the interaction > with other attributes of that object inherited from the caller) > explicit. That's good; combination of mutable attributes which > persist through a function invocation is the essence of object- > oriented programming. But it needs to be explicit or brains will > explode (more likely, they'll implode: instead of trying to figure out > whether an involutary namespace is present, developers will just go > ahead and assume it isn't, and pray they have a new job before it > blows up). > > Ben's post parallel to this one explains detailed examples of How > Things Can Go Wrong. > > I'm -1 on this (truncated from -1000). Python's simple, easy-to- > reason about behavior for assignments should not be messed with. > __getself__ and __setself__ are good names if we're going to have the > behavior, but it should be explicitly attached to an operator, not > invoked implicitly by assignment. (FWIW, I don't yet see a need for > the behavior, but I'm waiting on promised examples.) > > Steve > -- 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/345L35IAEX5AYRXZFDDSQCT2BBB5NTMK/ Code of Conduct: http://python.org/psf/codeofconduct/
