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. . 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: A direct link to the interpreter changes that support this can be found here:, 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 <> 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