...so would aliases be a bad idea? (Re: references / aliases in Python)

John Roth johnroth at ameritech.net
Thu Jan 16 02:50:58 CET 2003

"Jonathan P." <jbperez808 at yahoo.com> wrote in message
news:f57664b9.0301151625.65069704 at posting.google.com...
> > The Python philosophy regarding poiner types is simple: there aren't
> > Names are references to values. Attributes of objects are references
> > values. Elements of dictionaries, lists and tuples are references to
> > Values do not have names, they are simply bound by assignment (to
> > attributes of objects, or elements of dictionaries, lists and
tuples). Each
> > value (object) has an associated reference counter, incremented and
> > decremented automatically as references are created and destroyed.
When an
> > object's reference count reaches zero it becomes a candidate for
> > collection. Special features allow collection of "cyclic garbage" to
> > the cases where a set of objects refer only to each other.
> So if one allows 2 different names to bind to the exact same object,
> would that be a bad idea?  There are many situations where one
> would like a shorter name to bind to an object which might otherwise
> be only referrable to only by a very long chain of attributes.

One frequently has multiple names bound to the same object.
That's why objects have a reference count, after all. If you could only
bind an object to one name, you wouldn't need a count at all.

In a very real sense, all names are pointer types. If you want to
go further, you can get a very nice pointer type with a one element
list or tuple. The difference between a 'binding' and a 'pointer' in
this context is purely the way they are spelled.

Now aliasing two names for purposes of making the code shorter
is a different issue: one of code clarity rather than something required
by the algorithm you happen to be using.

My own feeling is that if you need to refer to many attributes of
an object you've probably got your hooks too deeply into the
internals of an object, and should think of a way to do whatever
you're doing with less coupling.

John Roth

More information about the Python-list mailing list