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/3b3714694b9cd9e2b1b706661765050c3..., 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 email@example.com 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.)
-- Nate Lust, PhD. Astrophysics Dept. Princeton University