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