[Tutor] value and object names

[Kent Johnson]

On Sun, Nov 2, 2008 at 5:11 PM, spir <denis.spir at free.fr> wrote:
> I have just read the following article:
> http://effbot.org/zone/python-objects.htm
> (thanks to a link on Kent's site). It is very good, I really recommend it.
>
> Still, a short passage has troubled my model about object names:
> "The names are a bit different — they're not really properties of the
> object, and the object itself doesn't know what it's called.
> An object can have any number of names, or no name at all.
> Names live in namespaces (such as a module namespace, an instance namespace,
> a function's local namespace)."
>
> What I guess: The second and third sentence seem to refer to variable names;
> meaning that objects 'live their life' whatever the number of variables (0,
> 1 or more) that point to them. These (variable) names are independant of the
> object -- and conversely.
> Now, the first sentence contradicts all what I thought I know on the topic!
> For me, not only /many/ types of objects have names, but they know about it,
> and these names are *really* bound to the object -- not to a variable
> pointing at it.

All three sentences are talking about variable names. Variable names
are not a property of the object referred to, and an object doesn't
know all the names it is bound to.

> Try the following:
>
> def smeagol():
>        pass
> print smeagol.__name__  # --> 'smeagol'
> gollum = smeagol
> print gollum.__name__   # --> 'smeagol'
>
> clear enough ;-)

Well...you have shown that functions have __name__ attributes that
contain the name that was given for the function when it was defined.
But gollum.__name__ == 'smeagol' shows the effbot's point, that the
function smeagol doesn't know that it is bound to the name gollum.

> I have the impression that what the article says applies to traditional
> built-in, non-object, data or values (or to the so-called C++ "data
> object"). In fact, even if types and classes are unified, even if values are
> object in Python, well, maybe some kinds of objects must remain different of
> others. Because there is a difference of nature.
> My model is that there is still a difference between 'real' values and
> 'real' objects.

No. *All* values are instances of some class. The article applies to all values.

> Values are things ordinary used to described a quality or property: bools,
> ints, strings...

No, values are instances of classes. You are making this too complicated.

> These things have no names.

You mean, they have no __name__ attribute.

> They have value representations
> instead. To access the integer usually written '1' or 'one', I need no name:
> I will use a conventional representation that happens to be '1' and is also
> used as its __repr__. When I write "a=1", I create a variable which is bound
> to 1 which name is 'a'. But 'a' has nothing to do with 1.
> print dir(1)
> [..., '__repr__', ...] # no name

The compiler knows about some kinds of literal values - numeric types,
strings, lists, dicts - but they are still instances of classes. They
just have some special compiler support.

> Now, 'real' objects, that we usually call class instances, that fit well in
> a model as parts of a system, have no representation. So that they need
> names: how could I access smeagol, once created, if it had no name?

The __name__ attribute of smeagol doesn't help you access it. You
access it through the name(s) it is bound to. In your example, you
could
del smeagol
to remove the name smeagol, and still access the function through the
name gollum.

You can also save references to values in collections and as
attributes of other classes; they may not be bound to any name.

When a value is not bound to any name (or otherwise referenced), it is
inaccessible and eligible to be garbage collected.

> On the
> other hand, such objects have no value. I mean no "natural" value. I can
> simulate a value for an instance by implementing several __xxx__ methods
> such as __eq__ (there may be a global __value__ method, I would love it).

They have the value of themselves. There is no such thing as a
"natural" value in Python.

You are making this too complicated. Python is in many ways very
simple, that is one of its strengths. You are drawing artificial
distinctions that don't make much sense to me.

One distinction that is used in Python is between mutable and
immutable values. Strings, numeric types and tuples are immutable -
they can't be changed after they are created. Lists, dicts and sets
are mutable - they can be changed.

Kent