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