Modifying Class Object

[Steve Holden]

* Duncan Booth:

Sure. I already did in the article you're replying to, immediately
following what you quote above. You snipped that which you're asking
for, so I requote:


<quote>
First, the current Python language specification formally prevents the
optimization you mention, because there's no support for binding to do
anything but direct binding leaving object identities unchanged.

But in practice that's no big deal though: I can't imagine any code
relying on identities of completely immutable objects.

Second, even the variant that was tried improved performance.

But it would reportedly have wreaked havoc with imperfect C code.

Third, the optimization doesn't do away with pointers. If it did then it
would transform the language completely. The user's view is still one
where names denote pointers.
</quote>


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.



No, I can't see how you can deduce any such connection from I wrote.

Whether objects "move around" depends on what exactly you mean by "move
around", and given that, it may then depend on the Python implementation.

However, from the Python point of view every object has a fixed unique
id, available via id().



I'm guessing wildly that you're trying to illustrate id's that don't
correspond to memory addresses?

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 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.

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.

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.

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.

regards
Steve

 

[Steven D'Aprano]

"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.

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;

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

(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");

(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.


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, and
consequently none of your arguments make the slightest sense to me. 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.

 

[Alf P. Steinbach]

* Steve Holden:

Alf P. Steinbach wrote: [snip]

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.
[snip]

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

 

[Alf P. Steinbach]

* Ethan Furman:

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

 

[John Posner]

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.

Alf, here's my suggestion on how to respond to people's criticisms of
your technical prowess: come up with the "best ever" description of
Python's variable-assignment and argument-passing schemes, and place the
description in your manuscript [1]. Section 2.4, "Naming things",
currently does not address the issues discussed in this thread ("pass by
XXX", etc.).

HTH,
John

[1] http://mail.python.org/pipermail/python-list/2009-December/1229932.html

 

[Arnaud Delobelle]

That's bullshit. [...]
not any that you know about. [...]
yet another ad hominem attack [...]
It also reflects rather badly on you. [...]
- Alf

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!

 

[Alf P. Steinbach]

* Steven D'Aprano:

Python doesn't have "copyable reference values" in the Python level. It
has objects.

Given

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;

No.

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
opposite.

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

 

[Steven D'Aprano]

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)

versus

"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.

 

[Alf P. Steinbach]

* Steven D'Aprano:

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.

No, it's the same.

String x;
somethingIDontRememberProbablyIo.println( x ) // Java equivalent

It's just different terminology, "NullPointerException" versus "unbound".

It's the same semantics.

Nothing substantial is changed by changing the Java message or changing the
Python message.

The word is just a word.

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)

versus

"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.

How a Python implementation implements local variables is irrelevant, except
that since references to local variables can be copied and *live on*, be used,
after a call, it has to work as if it uses implementation level pointers.

The notion of pointers (references) at the language level is not the same as the
notion of pointers at the implementation level.

This is the same as the notion of integers at the Python 3.x level (unbounded
values) is not the same as the notion of integers at the C or C# or Java level
(depending on the Python implementation, bounded values with wrap-around or
undefined behavior).

I.e. you're conflating two levels here.

You can perhaps more easily see that by considering an implementation of Python
in Python, using some computed counter as object id's. It doesn't change the
user view of copyable references. But it hides all that C pointer stuff two or
three abstraction levels down so that it becomes meaningless to talk about it.

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.
Right.


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.

Uhm, bad example (it wouldn't work exactly as described), but concerning what I
think you're trying to /communicate/, that X at the Python level is not the same
as X at the implementation level, like, 'int' at the Python 3.x level is not
'int' in C, and like, "pointer" at the Python level is not "pointer" in C: yes.



Cheers & hth.,

- Alf

 

[Steve Holden]

* Ethan Furman:

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.

So your accomplishments include mind-reading now, and you understand
everything that Stephen knows and does not know about? That's a
startling and, I suggest, untenable claim.

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.

So now the whole thing boils down to "Alf against the world"? The
reminds me of the story about the woman who went to see her son qualify
from his basic army training. When asked what she thought of the parade
she said it was very nice, but that "everyone but our Alf was out of step".

I am unsure at this stage what it would take to convince you that you
are not only wrong about several important aspects of Python but also
wrong-headed. Whenever anyone points out any aspect of your behavior
which is unacceptable or ignorant you trot out this accusation that
people are making "ad hominem attacks" as though commenting on aspects
of your personality is an attempt to undermine your arguments.

It isn't. The two are orthogonal. Your arguments are wrong *and* you are
behaving like a pratt. A change in either one of these aspects would
improve matters, but each seems as unlikely as the other.

It also reflects rather badly on you.

Sigh. We're all out of step again, obviously.

regards
Steve

 

[Alf P. Steinbach]

* Steve Holden:

So now the whole thing boils down to "Alf against the world"? The
reminds me of the story about the woman who went to see her son qualify
from his basic army training. When asked what she thought of the parade
she said it was very nice, but that "everyone but our Alf was out of step".

Considering your frequent ad hominem attacks (and this is yet one more), you
seem to think that social coercion works well for establishing engineering
solutions or scientific truth.

That's a misconception.

Social matters and matters of engineering or science are different things.

I am unsure at this stage what it would take to convince you that you
are not only wrong about several important aspects of Python but also
wrong-headed.

You might start by starting a thread about one such thing; I'll correct you if
you're wrong about something I know, or if you demonstrate that I'm wrong about
something, then I'll be happy to learn something, as always.

It would be a nice change from your extreme focus on my person, if you could
manage to discuss something technical.

Whenever anyone points out any aspect of your behavior
which is unacceptable or ignorant you trot out this accusation that
people are making "ad hominem attacks" as though commenting on aspects
of your personality is an attempt to undermine your arguments.

That's an ad hominem attack, albeit a pretty silly one.

Your behavior, with ad hominem, coercion, insinuations, misrepresentations and
so forth the basic ingredients, is completely unacceptable to me, by the way.

It's like a bully in the schoolyard.

It isn't. The two are orthogonal. Your arguments are wrong *and* you are
behaving like a pratt. A change in either one of these aspects would
improve matters, but each seems as unlikely as the other.


Sigh. We're all out of step again, obviously.

If you had any argument that held regarding the technical, then I think you (and
I mean the singular you) would have tried it by now.

But instead, you engage in this bullying behavior.


Cheers,

- Alf

 

[Steve Holden]

* Steve Holden:

Alf P. Steinbach wrote: [snip]

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.
[snip]

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.

*The* standard general language independent definition? As defined
where? The id() value doesn't "correspond to the pointer value", it
corresponds to the object. Why you see the need for this indirection
remains a mystery.

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



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

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

No, they access the objects. In the IronPython implementation, for
example, it has already been shown quite clearly that the id value is
simply an attribute of the object, whose values are incremented by one
for each new object.

For example,

x = s[0]

accesses the object that s points (refers) to.

It accesses (the first element of) the object bound to the name "s".

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

The 'is' operator is a simple test for equality of ids of the objects
resulting from the evaluation of two expressions. The expressions can be
literals, simple names, or any other valid Python expression. They are
*not* pointers, or references.

id() simply returns a unique value identifying a particular object. In
CPython, where objects do not migrate in memory once created, the memory
address of the object is used. In IronPython each object is assigned an
id when it is created, and that value is stored as an attribute.

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.



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

Well at least we have found one aspect of Python we agree on.

No, I don't disagree with that.
Good.

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



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

I am simply pointing out that to make your point you are relying on
abstractions which increasingly diverge from the reality of the Python
language. I don't think it's unreasonable to describe that as
"hand-waving". You apparently do.

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

Again with the mind-reading: you appear to have convinced yourself that
you are an authority on what I know.

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.

No, it doesn't uniquely represent a pointer, it uniquely represents an
*object*.

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.

Be careful when comparing static and dynamic languages. Java, being a
static language, has no equivalent to Python's NameError and
AttributeError, which both represent situations in which no object has
been bound to a name. In those cases it isn't that the name exists and
is bound to a "null pointer", it's simply that the name doesn't exist.
So there is no "copyable reference value".

regards
Steve

 

[Steve Holden]

* Steve Holden:

Considering your frequent ad hominem attacks (and this is yet one more),
you seem to think that social coercion works well for establishing
engineering solutions or scientific truth.

That's a misconception.

So now I understand neither engineering nor science? I find that
assertion offensive, though unsurprising.

Social matters and matters of engineering or science are different things.

I am hardly ignorant of that, as you should know from my many past
writings on both aspects of Python usage. You are attempting to teach
your grandmother to suck eggs.

I am unsure at this stage what it would take to convince you that you
are not only wrong about several important aspects of Python but also
wrong-headed.

You might start by starting a thread about one such thing; I'll correct
you if you're wrong about something I know, or if you demonstrate that
I'm wrong about something, then I'll be happy to learn something, as
always.

It would be a nice change from your extreme focus on my person, if you
could manage to discuss something technical.
See below.

Whenever anyone points out any aspect of your behavior
which is unacceptable or ignorant you trot out this accusation that
people are making "ad hominem attacks" as though commenting on aspects
of your personality is an attempt to undermine your arguments.

That's an ad hominem attack, albeit a pretty silly one.
[facepalm]

Your behavior, with ad hominem, coercion, insinuations,
misrepresentations and so forth the basic ingredients, is completely
unacceptable to me, by the way.

It's like a bully in the schoolyard.

I am attempting to persuade, not to coerce.

If you had any argument that held regarding the technical, then I think
you (and I mean the singular you) would have tried it by now.

But instead, you engage in this bullying behavior.

My (technical) views on your insistence that Python's semantics require
the use of pointers to explain them is ongoing elsewhere, and remains
open for you to refute.

In this particular part of the thread I am attempting, unsuccessfully,
to convince you that a change in *your* behavior would lead to less
hostility directed towards the way you present your ideas.

You apparently feel it is quite acceptable to tell people to "learn to
read", and calling their assertions "bullshit", but when we try to point
out aspects of your behavior that are either undesirable or unacceptable
we are indulging in "ad hominem attacks".

In your terms, your accusing me of bullying behavior is an ad hominem
attack on me, so I won't bother to respond further.

regards
Steve

 

[Steve Holden]

On Wed, Feb 10, 2010 at 7:49 PM, Steve Holden <[email protected]

*The* standard general language independent definition? As
defined where?


Wait, what happened here?

This thread started a couple days ago; you pointed out its futility, and
even knowing better, I jumped in the deep end. When I realized the
futility, you rightly I-told-you-so'd me.

You didn't have to pick up my slack

On Mon, Feb 8, 2010 at 6:42 PM, Steve Holden <[email protected]

Of course this won't make the slightest difference. "'When I use a
word,' said Humpty ..."

Yes, but someone on the Internet is wrong, dammit, I can't go to bed yet.

regards
Steve

 

[Alf P. Steinbach]

* Steve Holden:

* Steve Holden:

Alf P. Steinbach wrote: [snip]
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.
[snip]
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.

*The* standard general language independent definition?
Yes.


As defined where?

For example, as I used as reference in my first posting, the Java language spec.
But it has nothing specifically to do with Java. It is a basic concept in
computer science, that (most) CS students learn in their *first year*.

E.g.

<quote src="http://cslibrary.stanford.edu/106/">
A pointer stores a reference to something. Unfortunately there is no fixed term
for the thing that the pointer points to, and across different computer
languages there is a wide variety of things that pointers point to. We use the
term pointee for the thing that the pointer points to, and we stick to the basic
properties of the pointer/pointee relationship which are true in all languages.
The term "reference" means pretty much the same thing as "pointer" --
"reference" implies a more high-level discussion, while "pointer" implies the
traditional compiled language implementation of pointers as addresses. For the
basic pointer/pointee rules covered here, the terms are effectively equivalent.
</quote>

Note that that discussion at Stanford University has several Java examples + a
FAQ about the application of the term "pointer" to Java (plus of course that
that's specified by the language spec), so "implies ... pointers as addresses"
is not smart to get too focused on. Some common sense is required.

As mentioned, it is for first-year students.

But anyway, this is just terminology; if you don't like the term, then invent or
suggest one that you're able to grok or think others will more likely grok.

The id() value doesn't "correspond to the pointer value", it
corresponds to the object. Why you see the need for this indirection
remains a mystery.

The language specifies pointer semantics, that's all.

You can copy and replace references.

So, they quack like pointers, waddle like pointers and look like pointers: =
pointers.

No, they access the objects.

What's the difference between "access the objects" and "access the objects"?

I'm not genuinely interested in how you came up with this amazing rebuttal, it
was a rhetorical question only.

But I note that the only difference seems to be that you don't want the objects
to be referenced (pointed to) by anything, removing that bit of text, which
would make it a bit problematic to apply /any/ operation...

In the IronPython implementation, for
example, it has already been shown quite clearly that the id value is
simply an attribute of the object, whose values are incremented by one
for each new object.

Please demonstrate how that is relevant to whatever you're arguing.

For example,

x = s[0]

accesses the object that s points (refers) to.

It accesses (the first element of) the object bound to the name "s".
Yes.

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

The 'is' operator is a simple test for equality of ids of the objects
resulting from the evaluation of two expressions. The expressions can be
literals, simple names, or any other valid Python expression.
Yes.


They are *not* pointers, or references.

Simple demonstration that they're references (have reference semantics):

s = ["A"]
t = s # Copies the reference.
t[0] = "B" # Changes the referenced object via the reference copy.
print( s ) # Inspects object (now changed) via original reference.

It's pretty hard to argue seriously against this without committing a number of
fallacies.

Denial is of course easy, and you've done that, but it's at best just childish.

id() simply returns a unique value identifying a particular object. In
CPython, where objects do not migrate in memory once created, the memory
address of the object is used. In IronPython each object is assigned an
id when it is created, and that value is stored as an attribute.
Yes.


Well at least we have found one aspect of Python we agree on.

Oh, good.

I am simply pointing out that to make your point you are relying on
abstractions which increasingly diverge from the reality of the Python
language.

On the contrary, the closest abstraction to reference semantics is reference
semantics.

No special cases needed.

No extraneous conceptual ballast.

I don't think it's unreasonable to describe that as
"hand-waving". You apparently do.

Yes and no.

Regarding what you write now, that is regarding what people (who don't have set
positions) find easier to grasp: discussing that is necessarily handwaiving, but
to the same degree no matter which side you argue. Unless one applies
statistics. So by your own argument you're handwaiving.

On the other hand, regarding what you wrote earlier you implied a history of
handwaiving from me.

You would be unable to give examples of that.

But above you present an argument about IronPython which suggest some
unspecified contradiction with something unspecified (to get to the implied
contradiction a reader would have to form a picture that would be
misrepresenting me), and *that* is an example of handwaiving, diversion and
misrepresentation -- which I didn't have to look far to find...

Again with the mind-reading: you appear to have convinced yourself that
you are an authority on what I know.

What on Earth are you babbling about now? I say what I do. You therefore think
I'm reading your mind? Hello. Get a grip.

No, it doesn't uniquely represent a pointer,

Denial is just stupid, sorry.

it uniquely represents an *object*.

Yes, and that implies that it also uniquely represents a pointer to the object.
If nothing else you could take the address of the object and have a direct
correspondence (one-to-one mapping) with the id value, contradicting your
statement. But that's just one concrete example, it doesn't capture the general
idea of an abstract pointer: it only shows that your statement is a
self-contradiction, i.e., fallacious.

Be careful when comparing static and dynamic languages. Java, being a
static language, has no equivalent to Python's NameError and
AttributeError, which both represent situations in which no object has
been bound to a name. In those cases it isn't that the name exists and
is bound to a "null pointer", it's simply that the name doesn't exist.
So there is no "copyable reference value".

Yes, you have point there (the first so far, I must add, since this is at the
end of the article!). And it is a good but subtle point that I was a bit
hesitant to mention. But since you've let that cat out of ze bag, Java and
Python differ in what dangerous name/pointer features they offer: IIRC Java
allows a name to become "unbound" by assigning nullpointer, i.e. an extra path
to that dangerous nullpointer/unbound state, while Python allows a name to
become non-existent via del, i.e. an extra path to that dangerous non-existence.

Still, the unbound/nullpointer state is the same, with the same effect.

And that's quite suggestive.


Cheers & hth.,

- Alf

 

[Dino Viehland]

id() simply returns a unique value identifying a particular object. In
CPython, where objects do not migrate in memory once created, the
memory
address of the object is used. In IronPython each object is assigned an
id when it is created, and that value is stored as an attribute.

Just a point of clarification: In IronPython ids are lazily assigned upon
a call to the id(). They're actually fairly expensive to create because
the ids need to be maintained by a dictionary which uses weak references.

Just for fun this works in IronPython 2.6:
True

Please, please, no one ever use this code!

I do generally agree with the sentiment that id is object identity and in
way related to pointers though.

 

[Alf P. Steinbach]

* Steve Holden:

* Steve Holden:
Considering your frequent ad hominem attacks (and this is yet one more),
you seem to think that social coercion works well for establishing
engineering solutions or scientific truth.

That's a misconception.

So now I understand neither engineering nor science? I find that
assertion offensive, though unsurprising.

Social matters and matters of engineering or science are different things.

I am hardly ignorant of that, as you should know from my many past
writings on both aspects of Python usage. You are attempting to teach
your grandmother to suck eggs.

I am unsure at this stage what it would take to convince you that you
are not only wrong about several important aspects of Python but also
wrong-headed.

You might start by starting a thread about one such thing; I'll correct
you if you're wrong about something I know, or if you demonstrate that
I'm wrong about something, then I'll be happy to learn something, as
always.

It would be a nice change from your extreme focus on my person, if you
could manage to discuss something technical.
See below.

Whenever anyone points out any aspect of your behavior
which is unacceptable or ignorant you trot out this accusation that
people are making "ad hominem attacks" as though commenting on aspects
of your personality is an attempt to undermine your arguments.

That's an ad hominem attack, albeit a pretty silly one.
[facepalm]

Your behavior, with ad hominem, coercion, insinuations,
misrepresentations and so forth the basic ingredients, is completely
unacceptable to me, by the way.

It's like a bully in the schoolyard.

I am attempting to persuade, not to coerce.

If you had any argument that held regarding the technical, then I think
you (and I mean the singular you) would have tried it by now.

But instead, you engage in this bullying behavior.

My (technical) views on your insistence that Python's semantics require
the use of pointers to explain them is ongoing elsewhere, and remains
open for you to refute.

In this particular part of the thread I am attempting, unsuccessfully,
to convince you that a change in *your* behavior would lead to less
hostility directed towards the way you present your ideas.

You apparently feel it is quite acceptable to tell people to "learn to
read",

I have not used that expression.

However I have suggest and emphasized that it might help to *read* whatever one
quotes, when the quoted material (such as one paragraph) has not been read.

Telling someone to "learn to read" is a Steve Holden'sk way to imply that the
person is an ignoramus who hasn't bothered to learn to read. Telling a person to
read something that's obviously not been read is quite another matter. So, you
are misrepresenting -- again -- and in a quite revealing way, sorry.

and calling their assertions "bullshit",

Yes, in this group, but only for personal attacks.

Such as yours.

I think I've shown extreme restraint in the face of bullying from you and some
followers, and calling the insinuations bullshit is quite mild.

but when we try to point
out aspects of your behavior that are either undesirable or unacceptable
we are indulging in "ad hominem attacks".

That is an untrue and extremely misleading description of what you've been doing.

In your terms, your accusing me of bullying behavior is an ad hominem
attack on me, so I won't bother to respond further.

You're complaining about the person you're hitting saying clearly what you did.

If some truthful words about bullying can get you straight I'm for it.

Even if it means getting down to your level (and yes, I did).


Cheers,

- Alf

 

[Steven D'Aprano]

* Steven D'Aprano:

Python doesn't have "copyable reference values" in the Python level. It
has objects.

Given

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.

You keep making a habit of pretending that you know what other people are
thinking, accusing them of lying for having an opinion that differs from
yours, and of deliberately making silly arguments that the poster (in
this case, me) knows is untrue. It is an obnoxious, trolling habit.
Please stop it.

I don't "know" it is a silly argument, because I don't accept your
givens. Specifically:

s = [1]
t = s # Binds the name t to the object bound to the name s.
t[0] = 2 # Changes the object bound to the name t
print(s) # Checks the object via the original name.

Notice that your version describes what happens according to some
implementation, below the level of the Python virtual machine. My version
describes what happens at the level of high-level Python code, which is
the defined semantics of the language. It makes no assumptions about the
implementation, completely unlike yours which is entirely implementation-
specific. My description is equally valid whether Python is being
executed by the CPython virtual machine on an Intel-compatible processor,
or hand-simulated with pencil and paper, or something completely
different. Yours is not.

I describe the high-level language, you describe one implementation.
Neither view is *wrong*, per se, but one describes the semantics of the
language while the other describes the implementation.

The first paragraph of the Python docs about the execution model says:

"NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name
binding operations. Each occurrence of a name in the program text refers
to the binding of that name established in the innermost function block
containing the use."

http://docs.python.org/reference/executionmodel.html

Apart from the use of the generic English term "refers to" (and similar),
you will find *nothing* about pointers in this. That's because pointers
are not a part of the high-level behaviour of Python.

See also:

http://docs.python.org/reference/simple_stmts.html#assignment-statements

where you will also not find the word "pointer" used to describe any high-
level Python feature, or used in relation to assignment.

 

[alex23]

Telling someone to "learn to read" is a Steve Holden'sk way to imply that the
person is an ignoramus who hasn't bothered to learn to read.

Ad hominem.

So, you
are misrepresenting  --  again  --  and in a quite revealing way, sorry.

Ad hominem.

Yes, in this group, but only for personal attacks. Such as yours.

Ad hominem.

I think I've shown extreme restraint in the face of bullying from you and some
followers, and calling the insinuations bullshit is quite mild.

Ad hominem.

That is an untrue and extremely misleading description of what you've been doing.

Ad hominem.

Even if it means getting down to your level (and yes, I did).

Ad hominem.

So the real lesson you're trying to impart is to do as you say and not
as you do?

 

[Alf P. Steinbach]

* Steven D'Aprano:

* 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.

Given

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.

You keep making a habit of pretending that you know what other people are
thinking,

No, that is untrue, I do neither know nor pretend to know what other people are
thinking.

But I do know that you know some elementary things, such as understanding what
the code above does.

I do not by that mean that you don't also understand far more advanced things
, just that I'm fairly ~100% sure that you do understand the code above.

accusing them of lying for having an opinion that differs from
yours,

That is untrue.


[snip]

I don't "know" it is a silly argument, because I don't accept your
givens. Specifically:

s = [1]
t = s # Binds the name t to the object bound to the name s.
t[0] = 2 # Changes the object bound to the name t
print(s) # Checks the object via the original name.

Notice that your version describes what happens according to some
implementation, below the level of the Python virtual machine.

Consider just the

assert( t is not s )

t = s

Does this change anything at all in the computer's memory?

If it doesn't, then it has no effect whatsoever.

But since it does have an effect, a memory change has been effected.

You describe that memory change as that t has been "bound" to the same object as s.

By which you mean that henceforth, until the next assignment to t, t *refers* to
the same object as s.

That explanation in terms of "refers" is necessary. No beginner knows what it
means that a name is "bound" to something means, until it's been explained. The
explanation is necessarily in terms of "refers to".

When something A refers to something B, then by definition A is a *reference* to B.

Anyway, you have changed which object t refers to, by changing memory contents
so that t now refers to the same object as s.

Effectively, by making t refer to the same object as s, by all measures of
reference equality (which is just, do they refer to same object?) you have
*copied* the s reference to t.

For if you haven't, then t necessarily refers to something else.

So the memory change, whatever it was, involved an effective copying of a
reference, in memory.

And that copying of a reference, in memory, implies a copyable reference.

Going the other way, copying of references very directly implies binding. No
need for the long logic chain above. So copying of references is in my view much
more powerful as a model of what goes on, yielding immediate conclusions,
avoiding special case rules, and being very suitable for visualization.

Not the least, it's more powerful because in order to explain "bind" you need
"refer" and "reference", so the "bind" view involves more, violating Occam's.

But given the explanation in terms of "refer" and "reference" you do not need
"bind", so it's less, it's simpler -- and it's easier to visualize.


---


Anyway, there is more practical way to look at it.

Say that you're going to implement a linked list.

The functionality required for that is exactly that of general pointers. But a
linked list can be implemented in Python, using names (attributes) as pointers.
And since that works, without having to do anything extra in order to
"implement" pointers in terms of names, but just using those names directly,
those names necessarily have the functionality of general pointers.

My version
describes what happens at the level of high-level Python code, which is
the defined semantics of the language. It makes no assumptions about the
implementation, completely unlike yours which is entirely implementation-
specific. My description is equally valid whether Python is being
executed by the CPython virtual machine on an Intel-compatible processor,
or hand-simulated with pencil and paper, or something completely
different. Yours is not.

I describe the high-level language, you describe one implementation.
Neither view is *wrong*, per se, but one describes the semantics of the
language while the other describes the implementation.

The first paragraph of the Python docs about the execution model says:

"NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name
binding operations. Each occurrence of a name in the program text refers
to the binding of that name established in the innermost function block
containing the use."

http://docs.python.org/reference/executionmodel.html

Apart from the use of the generic English term "refers to" (and similar),
you will find *nothing* about pointers in this. That's because pointers
are not a part of the high-level behaviour of Python.

Well, apart from... As you say.

See also:

http://docs.python.org/reference/simple_stmts.html#assignment-statements

where you will also not find the word "pointer" used to describe any high-
level Python feature, or used in relation to assignment.

Yes, that's right.

It does not mean that such a description is invalid.

It only means that common sense needs to be applied, and that the urge to
misinterpret needs to be suppressed. I don't think those are problems for
novices. But still a better term than "pointer" would be nice, and I guess
"reference" is it, as suggested by the course material I linked to.


Cheers & hth.,

- Alf