Yes, the "value" of an object includes its type and memory location. You need to extract the attribute values you want. Note that you need to do this for the other objects included in the Song attributes.

One way to do this is to implement the "representation" method within your class, __repr__. For your application, it might look something like this:

def __repr__(self):
    return "\n".join([self.title, self.artist.name, self.album.title,
                      "Track " + str(self.track_number)])

Now, any time you use a Song object where its string representation is syntactically required, Python will use this method to make the conversion. Without any other coding, your program now produces:

[A Ballad about Cheese
Bob's Awesome Band
Bob's First Single
Track 0]
[A Ballad about Cheese
Bob's Awesome Band
Bob's First Single
Track 0, A Ballad about Cheese (dance remix)
Bob's Awesome Band
Bob's First Single
Track 1]
[A Ballad about Cheese
Bob's Awesome Band
Bob's First Single
Track 0, A Ballad about Cheese (dance remix)
Bob's Awesome Band
Bob's First Single
Track 1, A Third Song to Use Up the Rest of the Space
Bob's Awesome Band
Bob's First Single
Track 2]

Of course, you'll want to customize this to your own listing desires.

According to the manual, in CPython id() is the actual memory address of the variable. If you want it in hex format, call hex() on it.

x = 5
print hex(id(x))

this will print the memory address of x.

You could reimplement the default repr this way:

def __repr__(self):
    return '<%s.%s object at %s>' % (
        self.__class__.__module__,
        self.__class__.__name__,
        hex(id(self))
    )

You're almost certainly asking the wrong question, and Raymond Hettinger's answer is almost certainly what you really want.

Something like this might be useful trying to dig into the internals of the CPython interpreter for learning purposes or auditing it for security holes or something… But even then, you're probably better off embedding the Python interpreter into a program and writing functions that expose whatever you want into the Python interpreter, or at least writing a C extension module that lets you manipulate CPython objects.

But, on the off chance that you really do need to do this…

First, there is no reliable way to even get the address from the repr. Most objects with a useful eval-able representation will give you that instead. For example, the repr of ('1', 1) is "('1', 1)", not <tuple at 0x10ed51908>. Also, even for objects that have no useful representation, returning <TYPE at ADDR> is just an unstated convention that many types follow (and a default for user-defined classes), not something you can rely on.

However, since you presumably only care about CPython, you can rely on id:

CPython implementation detail: This is the address of the object in memory.

(Of course if you have the object to call id (or repr) on, you don't need to dereference it via pointer, and if you don't have the object, it's probably been garbage collected so there's nothing to dereference, but maybe you still have it and just can't remember where you put it…)

Next, what do you do with this address? Well, Python doesn't expose any functions to do the opposite of id. But the Python C API is well documented—and, if your Python is built around a shared library, that C API can be accessed via ctypes, just by loading it up. In fact, ctypes provides a special variable that automatically loads the right shared library to call the C API on, ctypes.pythonapi.

In very old versions of ctypes, you may have to find and load it explicitly, like pydll = ctypes.cdll.LoadLibrary('/usr/lib/libpython2.5.so') (This is for linux with Python 2.5 installed into /usr/lib; obviously if any of those details differ, the exact command line will differ.)

Of course it's much easier to crash the Python interpreter doing this than to do anything useful, but it's not impossible to do anything useful, and you may have fun experimenting with it.