[Python-ideas] objects aware of being bound to a name

[Terry Reedy]

On 6/4/2011 2:11 AM, Eric Snow wrote:
> When a name is bound to an object, the object doesn't hear about it,

Objects are created. Then they may *optionally* be bound to names 
(possibly in a different namespace) and collection slots. Or they may be 
used in an expression and be discarded without every being bound to 
anything.

 > usually.

I believe never.

 > The exceptions I could
> think of are class and function definitions, and imports.

Functions, classes, and modules have __name__ attributes (that cannot be 
deleted, even if they can be replaced). This attribute is set before 
they are optionally bound, so they also do not hear about the subsequent 
bindings. This attribute is used for their string representations for 
humans to read. I cannot think of any other use by the interpreter itself.

 > Also, you can sneak around it using
> setattr/descriptors if you control the class...  However, objects are
> otherwise (and generally) blind to their names.

Object (or definition or intrinsic or attribute) names (exactly 1 for 
certain instances of certain classes) and namespace binding names 
(0-many for every object) are different concepts. Ojects names live on 
the object. The binding names live in one of the many namespaces. Object 
names are not unique among objects. Binding names are unique within each 
namespace.

Objects names do not have to match any of the binding names of the 
object. A common type of example of this is

 >>> import itertools as it
 >>> it.__name__
'itertools'

> This is relevant when you want an object to be aware of the contexts
> in which it exists.

Python objects exist within an anonymous object space with no structure. 
They can be used within any namespace context from which they can be 
accessed via names and slots. Adding a __name__ attribute to instances 
of a class will not say anything about use context.

Modules carry source information in __filename__ for convenience in 
error reporting. Classes and functions have the *name* of their creation 
context in __module__ for the same reason. I do not believe that 
__filename or __module__ have any operational meaning after the object 
is created. For functions (but not classes) __globals__ *is* needed to 
function. Instances have __class__, which is used for both attribute 
lookup and information display.

 > It also relates to DRY issues that people bring up sometimes
 > with regards to descriptors and namedtuple (though
> I'm not sure its that big a deal).

If one wants an object name and initial binding name to be the same, I 
agree that giving the name once is a convenience. Def, class, and import 
*statements* allow this for functions, classes, and modules. Each has a 
syntax peculiar to the class. Lambda expressions, type() calls, 
__import__ calls (and others in inspect create objects with __name__s 
but without an automatic binding operation.

Ideas about not repeating duplicate object/binding names was discussed 
here in a thread with several posts within the last year. I believe one 
idea was a new 'augmented assignment': something like 'x .= y' meaning 
"y.__name__ = 'x'; x = y". But there was some problem with every proposal.

-- 
Terry Jan Reedy