From: Alf P. Steinbach on
* Steve Holden:
> Alf P. Steinbach wrote:
>> Since in the quoting above no reference to definition of "pointer"
>> remains: "pointer" refers to a copyable reference value as seen from the
>> Python level, in the same way as "pointer" is used by e.g. the Java
>> language spec.
>> If so, then that's correct: a Python (or Java, or whatever language)
>> pointer is not necessarily directly a memory address, and furthermore id
>> is not guaranteed to reproduce the bits of a pointer value -- which
>> might not even make sense.
>> All that id does is to produce a value that uniquely identifies the
>> object pointed to, i.e. it corresponds to the pointer value, and
>> although in CPython that's simply the bits of a C pointer typed as
>> integer, in IronPython it's not.
> You go too far here. What you are referring to in your bizarrely
> constructed definition above

No, it's not bizarre, it's the standard general language independent definition.

And since I'm referring to an external definition (Java) it's not mine, either. :-)

> as a pointer does not allow you to access
> the value that is "pointed to". So I fail to see why you feel its its
> introduction is necessary.

Python provides a number of ways to access the object pointed to.

Attribute access, indexing, and operators access the objects pointed to.

For example,

x = s[0]

accesses the object that s points (refers) to.

While 'is', 'id' and assignment operate on the pointers (references) themselves.

So there's one set of language features that operate on pointers, and one set of
language features that operate on the pointed to objects. This is so also in
Java and C#. For example.

> Whether in CPython, Jython or IronPython the value returned by calling
> id(x) (whether x is a literal, a simple name or a more complex
> expression) is absolutely no use as an accessor: it does not give you
> access to the referenced value.

Yes, the id does not give you access to the referenced object.

> If you disagree, please write (in any implementation you like: it need
> not even be portable, though I can't imagine why ti wouldn't be) a
> Python function which takes an id() value as its argument and returns
> the value for which the id() value was provided.

No, I don't disagree with that.

It would be excessively inefficient to do, involving enumeration of all objects.

> So in your world it's unnecessary for pointers to point to anything (or
> references to refer to something)? For someone who cheerfully admits to
> being wrong from time to time (an admirable characteristic) you are
> certainly difficult to convince on this point. One wonders what further
> hand-waving will follow.

He he, "further" handwaiving: you're good at unsubstantiated allegations.

I generally strive to provide concrete examples, and you know it.

Anywyay, treating the first sentence as a genuine question: in the most likely
interpretation it seems that you're conflating id's with pointers. An id() value
uniquely represents a pointer (i.e., the identity of the object pointed to). It
is not itself a pointer since it lack any pointer semantics.

For a less likely more technical interpretation, as far as I know in Python
there's just one case of a pointer that does not point to anything, namely as
exemplified by

def foo():
print( x )
x = "whatever"

The Java equivalent would say "NullPointerException", in Python it says
something like "unbound". Which means the same.

Cheers & hth.,

- Alf
From: Alf P. Steinbach on
* Ethan Furman:
> Steven D'Aprano wrote:
>> Believe me Alf, the fact that people are taking the time to try to
>> argue with you instead of just kill-filing you is a compliment.
> It's a compliment I am not paying, although I am grateful to those who
> are attempting to teach him. At the rate it's going, though, I don't
> see myself buying any book he produces.
> Besides the arrogant attitude, he is wrong on so many things about
> Python it is truly stunning.

That's bullshit. I am probably wrong about many Python things, for this is so no
matter the language and the practictioner, but not any that you know about.

> He seems to have confidence born of
> ignorance... a scary sight to see.
> In the spirit of being helpful and not just being a jerk myself:
> Alf,
> Using smileys after declaring somebody is mistaken/wrong/etc makes you
> look bad.
> Not attempting to learn the language makes you look like an arrogant
> idiot (case in point: passing-by-object).
> Accusing anyone and everyone that criticizes you of making ad hominem
> (sp?) attacks makes you look like a whiner.
> After all is said and done - if you had a truly good grasp of Python, I
> might buy your book even if you still had -- ummm -- a less than winning
> presence on the mailing list; but right now your understanding is not
> worth paying for.
> Hoping-this-helps-but-not-really-expecting-it-to-ly yours,

It's yet another ad hominem attack, which means that you're painfully aware of
supporting an untenable technical position, or supporting a clique of people.

It also reflects rather badly on you.

Cheers & hth.,

- Alf
From: Arnaud Delobelle on
"Alf P. Steinbach" <alfps(a)> writes:
> That's bullshit.
> not any that you know about.
> yet another ad hominem attack
> It also reflects rather badly on you.
> - Alf


The above was extracted from the last post from you but I could have
picked almost any of your recent endeavours. I've come to the
conclusion that you're not a cute furry alien with a long nose. You're
a big bad troll!

From: Alf P. Steinbach on
* Steven D'Aprano:
> On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote:
>> "pointer" refers to a copyable reference value as seen from the Python
>> level, in the same way as "pointer" is used by e.g. the Java language
>> spec.
> Python doesn't have "copyable reference values" in the Python level. It
> has objects.


s = [1]
t = s # Copies reference.
t[0] = 2 # Changes referenced object via copied reference.
print( s ) # Checks the object via the original reference.

your argument that the copied reference does not exist, is just silly.

And you know it.

> It seems to me that your argument is based on the premises:
> (1) that the "value" of a variable is not what 99.99% of people would
> describe as the value, but is some hidden, implementation dependent
> "pointer" instead;

No. The Python language spec defines what value of an object means. And people
use "value" with many different meanings, using Common Sense to arbitrate.

It would be senseless to try to pin down a single meaning of the word "value".

You're arguing against a position unrelated to mine.

> (2) that "pointer" doesn't necessarily mean what 99% of people who
> learned C or Pascal understand by pointer;


But although this is "just" a terminological issue, it's worth discussing.

I refuse to believe that 99% of C and Pascal programmers believe that "pointer"
only refers to the pointer implementation in their language of choice.

In my first article in this thread I specifically referred to the Java language
specification, which says, first sentence in ยง4.3.1 in the 3.0 spec, that

"The reference values (often just references) are pointers to these objects,
and a special null reference, which refers to no object."

which is relevant to Python because Java has the same semantics, although Java
"NullPointerException" is called "unbound" in Python (but this is again just
terminology, not semantics). I.e., the general pointer term /can/ be used, and
is used, for reference values. Only a willingness to misinterpret can cause
confusion, at least when the terminology is defined, as I've done all the time.

Secondly I referred (actually that was in response to you) to a Stanford
University introduction to pointers, comparing four languages including Java.

I didn't refer you to Wikipedia because that article seems to lack mention of
reference based languages and does include a reference to an article that I
wrote about pointers in C++ (now off-net), and given the noise level here it
would therefore probably not help.

> (3) that mangling both common English and programmers' expectations in
> that fashion is somehow more accurate and more useful than using the 35
> year old term "call by object" (or "call by object reference");

No, I haven't stated any opposition to using that term; the archives show the

So for the second time here you're arguing against a silly position that I do
not hold.

> (4) and, presumably because of some deeply-held belief that the only
> parameter passing strategies that we're allowed to talk about are "call
> by value" and "call by reference", no matter how much violence we do to
> the concept of both value and pointer, Python and Java must be call-by-
> value since they clearly aren't call-by-reference.

Well that's the third time here that you're arguing against a silly position
that I do not hold.

> Of these, the only one that I consider value is that Python and Java are
> not call-y-reference. Otherwise, I reject all these premises,

Good rejection as far as 1, 3 and 4 are concerned.

Regarding the term "pointer", your point 2, I strongly encourage you to seek out
the sources I've referenced and quoted.

For without a common language it's difficult to communicate, and if Python
programmers should continue to not understand common terms then that would just
further flame wars such as this thread has escalated to. Please seek out
sources. Don't just take my word, instead, read e.g. what I've quoted, try out
the example I've given, and so on: be critical (to your own assumptions also!).

> and
> consequently none of your arguments make the slightest sense to me.

Well, you'd first have to examine at least one of my arguments. In this article
you haven't, instead attacking a number of positions that I haven't advocated
and do not hold, except for your silly denial of existence of references at the
top. But that's just silly -- consider the concrete example given.

> You
> keep talking about Python operating on pointers. I've never used a single
> pointer in 10+ years of Python coding, no matter how many times you tell
> me I have. What the implementation of the Python virtual machine does is
> not what I do high-level Python code, and the implementation is not the
> language.

Here again you're conflating things and engage in a kind of denial coupled with
a correct argument. It's hard to argue against such confusion. Instead I've
tried above to address your only relevant point, by a concrete example.

Summing up, denying the existence of references, as you do at the top, is just
silly; do consider the code example.

Your points 1, 3 and 4 attack positions that I do not hold and have not advocated.

Your point 2, about terminology, is important on its own. And I suggest you
check out the references I've given. And read what I quoted from the language
specification of a language with the same semantics as Python.

Cheers & hth.,

- Alf
From: Steven D'Aprano on
On Wed, 10 Feb 2010 23:02:27 +0100, Alf P. Steinbach wrote:

> For a less likely more technical interpretation, as far as I know in
> Python there's just one case of a pointer that does not point to
> anything, namely as exemplified by
> def foo():
> print( x )
> x = "whatever"
> The Java equivalent would say "NullPointerException", in Python it says
> something like "unbound". Which means the same.

Not in plain language. NullPointerException means that x is assigned to a
null pointer, and you have tried to follow that pointer. Unbound means
that x has nothing assigned to it. Semantically, the difference is
somewhat analogous to the situations:

"the president is dead, and a new president hasn't yet been appointed"
(the office of the president is currently assigned to a dead guy)


"the king has dissolved parliament and with it the office of president"
(there is no president at all)

Now, of course we understand that in the implementation of CPython, local
variables are stored efficiently in slots in an array, and you can't have
empty slots: every address always has some bit pattern. It is very likely
that the CPython implementation uses a nil pointer to indicate an empty
slot just like Java does. The difference is that Java exposes that
implementation decision as part of the language specification, while
Python deliberately does not.

It isn't an accident that the Python exception describes the *semantics*
of the error (x is not bound to any value) rather than the implementation
detail (the slot known as x has a nil pointer in it). Semantically, the
Python language treats the slot as empty and leaves the details of how
the implementation recognises empty slots as an implementation decision.

I'm just as interested by the implementation decisions made in CPython as
the next guy, but they don't effect the semantics of the high level
Python language. Here is a thought experiment for you:

One can imagine an implementation of Python that eschews all pointers for
some scheme by which objects are cleverly copied and synchronized as
needed. Such an implementation would still be Python, but it would be
entirely pointer-free.