Terminology: "reference" versus "pointer"

Steven D'Aprano steve at pearwood.info
Tue Sep 15 16:26:32 CEST 2015

On Tue, 15 Sep 2015 03:34 am, Random832 wrote:

> On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
>> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
>> > That's not true in CPython. In fact, the range object in python
>> > contains *four* reference boxes - one more for length.
>> I really don't see why any of this is relevant to the business being
>> discussed.
> When you're drawing this sort of diagram then what references are held
> by an object are more important than what interfaces it implements.

Hmmm. Well, that's going to be tricky then, at least for some objects. Take
a function object, for example:

func --------> | function object |

Nice and simple if you draw it like that. Or:

func --------> | function object   |
               |                  -|-------> ...
                 |          |  |
                 |          |  +---> ...
                 V          |
               +---------+  |
               | __doc__ |  +------> ...

Due to laziness, the diagram is incomplete. But here is a partial list of
references held by each function object. For brevity, I have not included
the leading and trailing underscores:

doc (string, or None);
annotations (dict mapping strings to arbitrary objects);
class (type object);
closure (None, or closure object);
code (code object)
dict (dict mapping strings to arbitrary objects);
module (string)
name (string)

and various more. Some of them, such as __code__, themselves include
references to many other objects. Even relatively small diagrams with only
a few objects could easily expand in complexity.

> Personally I think it's a bit silly to insist on a diagram model where a
> box with an arrow in it pointing at an int object can't be represented
> by a box with an integer in it (where 'int' is any immutable type -
> string, tuple, even range), but people don't like boxes with integers in
> them for some reason.

What's wrong with this?

myint ---------------> |  23  |


More information about the Python-list mailing list