Modifying Class Object

[Steve Holden]

+1 !!

+1000

 

[Alf P. Steinbach]

* Steve Holden:

* Steve Holden: [...]

Alf:

This topic was discussed at great, nay interminable, length about a year
ago. I'd appreciate it if you would search the archives and read what
was said then rather than hashing the whole topic over again to nobody's
real advantage.

Well that's my point, and thanks for backing me up on that : it's
very simple, and as demonstrated can be expressed in 10 words or less
(plus perhaps a terminology reference, as I did above), so all that
discussion and in particular the lengthy article at effbot serves as
obfuscation and nothing else.

Please don't assume I was trying to support you. Your remarks showed
considerable ignorance of issue that were extremely nuanced. Whatever
point you were trying to make was lost in your self-aggrandizing
disrespect of Fredrik Lundh, a software engineer of some repute with a
long history of contribution to Python. The fact that your post was
basically a restatement of one of the several competing positions in
that thread makes it no more right than any of the others.

What on Earth are you babbling about?

Perhaps next you'll drag in the Pope, saying I've shown him some disrespect.

News for you: the Pope ain't participating.

Why thank you for the education. Somehow in my 40-odd years of
programming I had quite overlooked that fact. Which helps how?

Which IMHO you have done little to assist. Just how exactly *do* we
succeed in asking you not to discuss something?

That's just a silly as the above. Hello? *Not* discuss an on-topic topic?

Anyways, we haven't reached discussion yet, if it will ever come to that.

All I see is a lot of silly noise about a simple trivially true technical
statement, with incoherent allegations of disrespect to the Pope, the current
king of France, and whomever, unfortunately as usual in this group. :-(



Cheers & hth.,

- Alf

 

[T]

Oops, this one was my fault - the object I was having the issues with
was actually a shelve file, not a dictionary..so just re-assigning the
variable isn't working, but re-writing the object to the shelve file
does.  So in this case, is there any way to just change a single
value, or am I stuck rewriting the entry?

Either open the shelve with writeback=True or rewrite the entry.
Rewriting the entry isn't hard: you can just re-use the same value:

def changevalue():
    for key in mytest.keys():
        temp = mytest[key]
        temp.param3 = "newvalue"
        mytest[key] = temp

If you really are changing every item in the shelve using writeback=True
will be much simpler, but if you are only changing a few then just tell the
shelve that you've updated them as above.

Duncan - Thanks for your help. So each of the shelve entries I'm
modifying look something like this: myshelve[key] =
TestClassObject(param1, param2, param3, param4, param5, etc.). In
this case, with quite a few parameters, would you suggest setting
writeback=True and just modifying the needed value, or rewriting the
entire entry? I have to admit the writeback option looks good, and if
the TestClassObject format ever changes (i.e. if I ever change the
order of the params), this particular function will be unchanged.
However, I don't know what the performance hit would be in using it.

 

[MRAB]

How do I get a pointer in pure Python code (no ctypes)? I tried both
Pascal and C syntax (^x and *x), but both give syntax errors.

In Pascal it's x^.

 

[MRAB]

* Steve Holden:

* Steve Holden: [...]
Alf:

This topic was discussed at great, nay interminable, length about a
year
ago. I'd appreciate it if you would search the archives and read what
was said then rather than hashing the whole topic over again to
nobody's
real advantage.
Well that's my point, and thanks for backing me up on that : it's
very simple, and as demonstrated can be expressed in 10 words or less
(plus perhaps a terminology reference, as I did above), so all that
discussion and in particular the lengthy article at effbot serves as
obfuscation and nothing else.

Please don't assume I was trying to support you. Your remarks showed
considerable ignorance of issue that were extremely nuanced. Whatever
point you were trying to make was lost in your self-aggrandizing
disrespect of Fredrik Lundh, a software engineer of some repute with a
long history of contribution to Python. The fact that your post was
basically a restatement of one of the several competing positions in
that thread makes it no more right than any of the others.

What on Earth are you babbling about?

Perhaps next you'll drag in the Pope, saying I've shown him some
disrespect.

News for you: the Pope ain't participating.

[snip]

The Pope isn't (as far as we know) a Pythonista.

 

[Diez B. Roggisch]

Am 08.02.10 02:51, schrieb Alf P. Steinbach:

* Chris Rebert:

Hm. While most everything I've seen at effbot.org has been clear and to
the point, that particular article reads like a ton of obfuscation.

Python passes pointers by value, just as e.g. Java does.

There, it needed just 10 words or so. Or perhaps some more words to
point out that in the Java language spec those reference values are
called pointers, but that this terminology isn't (apparently) used for
Python, and isn't even well known among Java programmers. But that's
just one extra little para.

One just has to be clear about exactly what it is that's passed by value.

Not Python objects, but references (pointers) to them, the id(o) values.

Whao. You just needed 10 words, plus a paragraph to explain something in
terms of a spec that's just about 600 pages strong. Amazing display of
conciseness, and certainly the most valuable thing for some programming
newbie to work with. Thanks!

Diez

 

[Alf P. Steinbach]

* Diez B. Roggisch:

Am 08.02.10 02:51, schrieb Alf P. Steinbach:

Whao. You just needed 10 words, plus a paragraph to explain something in
terms of a spec that's just about 600 pages strong. Amazing display of
conciseness, and certainly the most valuable thing for some programming
newbie to work with. Thanks!

I apologize for assuming that "pointer" is a known word to [c.l.p.] denizens.

But, if it can help, although for clarity I had to provide a concrete reference,
you don't need to read the complete Java language spec to understand that word.

Just Google it.


Cheers & hth.,

- ALf

 

[Alf P. Steinbach]

* alex23:

Must. Resist. Ad hominem.


10 words _plus_ an understanding of Java.

No, one only needs an understanding of "pointer".

"Pointer" is a mostly language independent concept.

The reference to the Java language spec, where that term is used for this, was
just an unsuccessful attempt to keep out word-play arguments based on the
incompatibility of some incompatible meaning of "pointer"...


Cheers & hth.,

- Alf

 

[Steve Holden]

Stephen Hansen wrote:
[...]

P.S. I couldn't resist.

And here I was, sitting on my hands ... but someone was wrong on the
Internet, so D'Aprano had to put them right. Your fatal weakness.

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

regards
Steve

 

[MRAB]

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

Stephen Hansen wrote:
[...]

P.S. I couldn't resist.

And here I was, sitting on my hands ... but someone was wrong on the
Internet, so D'Aprano had to put them right. Your fatal weakness.

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


This is getting out of hand.

First, someone thought I was you.

Now you think I'm D'Aprano.

I'm just gonna go by Bob for now on.



--B

Bruce would be less confusing.

 

[Alf P. Steinbach]

* Stephen Hansen -> Alf P. Steinbach:

[snip]
To say, "pass by value" implies things to people. It describes a sort of
world where I'm a function about to do some work, and on my desk I have
a series of boxes with names on it. It describes an environment where
someone comes over and drops something into each of my boxes. The
contents of these boxes are mine alone!

Then, when the imprecision makes people misunderstand, one should not say that.

One should then be more precise.

One should say /what/ is passed by value.


[snip]

... a += a
... return a
...

test1 = 1
test2 = doit(test1)
test1 1
test2 2
test3 = [1]
test4 = doit(test3)
test3 [1, 1]
test4

[1, 1]

I know you already know this, but the point is: you're -hurting- other
peoples understanding by using terms like this that don't apply to
Python's specific nature.

The terms apply very well to Java. And Java has the identical parameter passing
mechanism for class type objects. Hence, the argument is bogus.


Cheers & hth.,

- Alf

PS: I cannot see any of your postings on Usenet. So I just sort of grabbed this
from GMane and posted to Usenet. Hopefully you'll see it back at the list.

 

[Terry Reedy]

I apologize for assuming that "pointer" is a known word to [c.l.p.]
denizens.

It is irrelevant.

Python calls Python functions by associating argument objects (or
objects derived therefrom) with paramenter names, very much like
assigment statements.

If one understands Python objects, names, and assignment statements,
which one must to understand Python, this completely explains the
function calls, function execution, and its effect on passed objects.

All Python expressions evaluate to an object. Call expressions evaluate
to the object returned by the function.

Different interpreters implement call and return differently. Certainly,
most humans do not use C pointers when they mentally execute Python code.

Terry Jan Reedy

 

[Alf P. Steinbach]

* Terry Reedy:

I apologize for assuming that "pointer" is a known word to [c.l.p.]
denizens.

It is irrelevant.

Python calls Python functions by associating argument objects (or
objects derived therefrom) with paramenter names, very much like
assigment statements.

Well, part of the above is word-play. When a name refers to an object elsewhere
and that reference can be copied around, then it is a pointer to the object in
e.g. the Java sense, which I very purposefully referenced to be clear about it.
So you're saying that X is irrelevant in Python because Python uses Y, where Y
is a description of X...

But part of what you write puzzles me.

As far as the language spec is concerned the argument passing mechanism seems to
me to be identical to assignments, not just "very much like".

Your phrase "or objects derived therefrom" seems to imply that immutable objects
can be copied (an optimization that once was rejected), but as far as I can see
the language spec only talks about binding with no provision for binding to do
anything else than making a name refer directly to a specified object,
presumably with *the same id*.

Not talking about things built on top of argument passing like *, and not
talking about scopes or other (in this context) extraneous details: is there
something I've overlooked in the basic mechanism?

If one understands Python objects, names, and assignment statements,
which one must to understand Python, this completely explains the
function calls, function execution, and its effect on passed objects.

Yes.

There are many ways to understand it though.

The simplest description, reality, that names refer to objects, where those
references can be copied, i.e. that they in e.g. the Java sense are pointers to
objects, seems to be simplest -- and is certainly shortest.

All Python expressions evaluate to an object. Call expressions evaluate
to the object returned by the function.

Different interpreters implement call and return differently. Certainly,
most humans do not use C pointers when they mentally execute Python code.

The Java language spec reference for "pointer" was to avoid arguments about
irrelevant specialized meanings of the term, such as C pointers.


Cheers & hth.,

- Alf

 

[Steven D'Aprano]

* Stephen Hansen -> Alf P. Steinbach:

[snip]
To say, "pass by value" implies things to people. It describes a sort
of world where I'm a function about to do some work, and on my desk I
have a series of boxes with names on it. It describes an environment
where someone comes over and drops something into each of my boxes. The
contents of these boxes are mine alone!

Then, when the imprecision makes people misunderstand, one should not
say that.

One should then be more precise.

One should say /what/ is passed by value.

I don't see how that matters. Python's behaviour is EXACTLY the same, no
matter what you pass to the function.

You don't pass pointers in Python, because you, the Python author, have
no way of specifying a pointer in Python code. It is *always* an object
that you pass, by giving a literal, the name an object is bound to, or
some other expression that returns an object:

function( my_object )
function( 12345 )
function( ham(3) + spam(5) )

If you're talking to the person who writes Python code, then you should
discuss the sorts of things that exist in Python: objects and names and
expressions, but no pointers.

If you're talking about the Python virtual machine, instead of the high-
level Python code, then you should say so -- but there are still no
pointers in the VM. Look at the output of dis.dis and you will see
objects pushed onto a stack, but no pointers.

It's not until you get past the level of Python code, past the virtual
machine, and into the implementation of the virtual machine, that you
will finally find pointers.

But why stop there? If somebody asks you a question about Python, and you
choose to ignore them and answer a different question about one
particular implementation's internals instead, I don't see why you stop
there. Why not go down another layer and talk about copying bytes, or two
layers and answer that Python does call-by-bit-flipping, or a layer below
that and say it's all done by varying potential differences?

You shouldn't expect your listener to understand machine code to
understand Python's high-level behaviour, nor should you expect them to
be C coders. You don't need to understand pointers to understand a
language that doesn't support them.


[...]

The terms apply very well to Java. And Java has the identical parameter
passing mechanism for class type objects. Hence, the argument is bogus.

Everything I've said applies to Java as well, and the argument about call-
by-whatever is just as prevalent in Java circles as in Python.

Example #1:

Q: If Java uses the pass-by reference, why won't a swap
function work?

A: Your question demonstrates a common error made by Java
language newcomers. Indeed, even seasoned veterans find
it difficult to keep the terms straight.

Java does manipulate objects by reference, and all
object variables are references. However, Java doesn't
pass method arguments by reference; it passes them by
value.

http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html


Example #2:

Myth: "Objects are passed by reference, primitives are
passed by value"

Some proponents of this then say, "Ah, except for immutable
objects which are passed by value [etc]" which introduces
loads of rules without really tackling how Java works.

http://www.yoda.arachsys.com/java/passing.html


Example #3:

Java is Pass-by-Value, Dammit!

http://javadude.com/articles/passbyvalue.htm


Java programmers suffer for a bad mental model just as much as Python
programmers.

All this is because of two conceptual mistakes: (1) the Java community
has conflated the internals of what happens in the implementation of the
Java VM with high-level Java code; and (2) a refusal to accept that there
are calling strategies other than pass-by-value and pass-by-reference.

 

[Dennis Lee Bieber]

I've heard that, and can't fathom the claim. I've only ever met a single
Bruce in my entire life, though I've seen a couple on the 'net. Maybe its
geographical, and Bruce's just don't like California? I dunno.

Isn't Bruce a shark? http://www.imdb.com/character/ch0003722/ and
http://www.fishingfury.com/20090817/bruce-the-shark/

We seem to have a few sharks around at times...

 

[Alf P. Steinbach]

* Stephen Hansen:

On Mon, Feb 8, 2010 at 8:01 PM, Alf P. Steinbach <[email protected]

* Stephen Hansen -> Alf P. Steinbach:


[snip]

To say, "pass by value" implies things to people. It describes a
sort of world where I'm a function about to do some work, and on
my desk I have a series of boxes with names on it. It describes
an environment where someone comes over and drops something into
each of my boxes. The contents of these boxes are mine alone!


Then, when the imprecision makes people misunderstand, one should
not say that.

One should then be more precise.

One should say /what/ is passed by value.


No.

One should not use the phrase that is fundamentally imprecise.

The phrase "pass by value" means something different then the phrase
"pass by object" aka "pass by sharing". They are in many cases very
similar. They are not the same.

Right.

"pass by value" is a lower level notion.

And as you show below, in the paragraph marked [1], it can be used to describe
call by sharing very succinctly and precisely, just as I did... ;-)

Using it is simply wrong. There is
really no legitimate argument you can make otherwise: even in languages
where call-by-value IS the norm, the phrase is imprecise enough to
confuse people, as the semantics of what call-by-value mean to a
language vary. But those semantics do NOT apply to Python.

In a way that's right, but only at the level of abstraction of pass by sharing.

At that level it's wrong to say that pass by sharing is pass by value (as they
reportedly do over in Java-land), just as, at that level, it's wrong to say that
pass by reference is pass by value notwithstanding that some kind of value must
be copied in the internal implementation.

Describing pass by sharing in terms of pass by value is however very simple and
legitimate, involving a higher level described in terms of a lower level -- as

[snip]
I know you already know this, but the point is: you're -hurting-
other peoples understanding by using terms like this that don't
apply to Python's specific nature.
The terms apply very well to Java. And Java has the identical
parameter passing mechanism for class type objects. Hence, the
argument is bogus.


[1] Java uses silly terminology; and that it chooses to use silly
terminology in no way impacts the validity of the argument. Java isn't
an authority. Python's been around longer! And the specific behavior
here, "call by value where the value is an object reference" was named
"call by sharing" back in the 1970's by Liskov.

Yep.

As you write, "call by sharing" can be described as "call by value where the
value is an object reference".

Althuogh I'd rather use "where the value is an object pointer", because the word
"pointer" already denotes a copyable value so doesn't make the head spin...

Java isn't call-by-value (for objects) either, even if that phrase is
common in the Java community.

Right, and here the parenthesis (for objects) establishes which abstraction level.

C is call-by-value. VB is, I believe,
call-by-value -- though I may be wrong here, as I only sort of blinked
at VB a long, long time ago.

Full VB supports both call by sharing and call by reference.

Its distinct. Its different. Its neither call-by-value, nor
call-by-reference. The /value/ of a thing is NOT its identity. Its the
/state/ of that thing.

Talking about a reference value (a.k.a. pointer), as you do earlier above in
[1], does not mean that one is talking about a Python object value.

So essentially the paragraph immediately above seems to be a confusion based on
multiple meanings of "value", unless it's just a description of Python objects?

By your argument, call-by-reference is call-by-value too! Because you're
passing "a value" -- but you're -always- going to pass some piece of
data, otherwise you're not actually passing anything.

No, whatever you think my argument is (no quote, so I'm left in the dark about
that assumption) here you're back to confusing levels of abstraction again.

Call by reference is necessarily, at some level, implemented in terms of call by
value.

That doesn't make call by reference the same as call by value, not more than the
human body is one giant molecule just because it consists of molecules.

The /by value/ vs /by reference/ vs /by sharing/ is not about "is a
value being passed", in all cases, "a value" is. By Value means a copy
of the thing is made. By Reference means you're accessing the callers
variable directly. By Sharing means you're both sharing the same object.

Yes, violent agreement.

PS: I cannot see any of your postings on Usenet. So I just sort of
grabbed this from GMane and posted to Usenet. Hopefully you'll see
it back at the list.


I've heard that before, and have no idea why, nor any real interest in
solving it: I don't want to read cpl via Usenet, and prefer to read it
as a mailing list. Somewhere between Gmail->python.org->python.org
<http://python.org>'s usenet server->the world, some people don't seem
to get my posts. Yet it shows up on some news servers, not others.

No idea. Nothing I know of can solve it.

Not sure, but perhaps it's possible to mail directly to gmane?


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Steven D'Aprano:

* Stephen Hansen -> Alf P. Steinbach:

[snip]
To say, "pass by value" implies things to people. It describes a sort
of world where I'm a function about to do some work, and on my desk I
have a series of boxes with names on it. It describes an environment
where someone comes over and drops something into each of my boxes. The
contents of these boxes are mine alone!

Then, when the imprecision makes people misunderstand, one should not
say that.

One should then be more precise.

One should say /what/ is passed by value.

I don't see how that matters. Python's behaviour is EXACTLY the same, no
matter what you pass to the function.

You don't pass pointers in Python, because you, the Python author, have
no way of specifying a pointer in Python code. It is *always* an object
that you pass, by giving a literal, the name an object is bound to, or
some other expression that returns an object:

function( my_object )
function( 12345 )
function( ham(3) + spam(5) )

Every name and literal above (and in Python generally) stands for a copyable
reference to an object, not for the object itself. You can copy the reference:

a = [123]
b = a
assert( a is b ) # Doesn't matter if mutable or immutable or what.

A copyable reference is a pointer. That is, a "pointer", in e.g. the Java sense,
and in the general language independent sense, means a copyable reference --
as illustrated e.g. in the Stanford computer science 101 course page I
referred you to earlier, with C versus Java pointers illustrated in the concrete.

Hence, since every name and literal above stands for a copyable reference, and
since a copyable reference is a pointer, every name and literal above stands for
a pointer -- that's /all/ that you handle directly in Python, namely pointers.

But if that terminology sounds bad or has too strong C-vibes or Java-vibes or
whatever, then we just need some other term for a Python "copyable reference".

If you're talking to the person who writes Python code, then you should
discuss the sorts of things that exist in Python: objects and names and
expressions, but no pointers.

Well, given this terminology debate we may need some other term.

But IMHO the horse drawing the wagon needs to be mentioned to the potential
wagon driver, whatever that horse is called -- fourfooter, drawing-animal...

Anything else seems just senseless, meaningless abstraction, replacing one
simple single concept with a load of connections and special case rules.

If you're talking about the Python virtual machine, instead of the high-
level Python code, then you should say so -- but there are still no
pointers in the VM. Look at the output of dis.dis and you will see
objects pushed onto a stack, but no pointers.

I don't think you will see any Python objects pushed on the stack. But you will
see copyable object references pushed on the stack. That is, you will see
pointers pushed on the stack.

It's not until you get past the level of Python code, past the virtual
machine, and into the implementation of the virtual machine, that you
will finally find pointers.

There too.

But why stop there? If somebody asks you a question about Python, and you
choose to ignore them and answer a different question about one
particular implementation's internals instead, I don't see why you stop
there. Why not go down another layer and talk about copying bytes, or two
layers and answer that Python does call-by-bit-flipping, or a layer below
that and say it's all done by varying potential differences?

I think a good professional programmer knows about all these levels.

Unfortunately, at least about 10 years ago students fresh out of college in
Norway did not know about "internal" things such as call stacks, which led them
to adopt many Unholy Programming Practices and to be Extremely Baffled by things
such as stack traces.

You shouldn't expect your listener to understand machine code to
understand Python's high-level behaviour, nor should you expect them to
be C coders. You don't need to understand pointers to understand a
language that doesn't support them.

From the above comments it seems you're thinking about C pointers. To prevent
that misconception I've defined the term "pointer" in every or most every
posting I've made in this thread, including this posting. I've also posted a
link to a Stanford University page with a simple-words explanation (they even
have an animated Bunny video, although I've not looked at it); it's CS 101.

You don't have anything /but/ pointers in Python.

So pointers are key -- by whatever name.


[snip]

Java programmers suffer for a bad mental model just as much as Python
programmers.

Yes.

All this is because of two conceptual mistakes: (1) the Java community
has conflated the internals of what happens in the implementation of the
Java VM with high-level Java code; and (2) a refusal to accept that there
are calling strategies other than pass-by-value and pass-by-reference.

I'm not entirely sure about causes, but there is a tendency in general for
humans to go from one extreme to another that they regard as "opposite". Using
the term "call by value" for the Java (and Python) parameter passing is just
Wrong(TM), at least without a clear understanding of what can be passed. Using
"call by value" in a description of that model, mentioning very clearly what's
passed, is on the other hand very practical: it's short, succinct & correct.


Cheers & hth.,

- Alf

 

[Steven D'Aprano]

You don't have anything /but/ pointers in Python.

x = 5
y = "hello"

You want us to accept that the values of x and y are some mysterious
pointer entities rather than the integer object 5 and the string object
"hello".

At the point that your explanation depends on the reader understanding
that the value of a variable x is not actually the thing that they assign
to x, but some mysterious, invisible entity that exists entirely inside
the implementation where the user can never reach, you probably should
rethink your attachment to that explanation. No wonder so many Java
programmers are still confused by it.

It might help your case if we had a word for the thing that is actually
assigned to the variable. In plain English that is "value", but you want
to use that for the pointer to the thing-that-we-otherwise-would-call-
value, which leaves us no simple way to talk about the int 5 and string
"hello".

 

[Alf P. Steinbach]

* Steven D'Aprano:

x = 5

The above assigns to x a pointer to an object whose value is 5:

x ------> 5

y = "hello"

Ditto result:

y ------> "hello"


And if now do

x = y

then the code is assigning (copying) to x the pointer in y:

x -----------
\
y ---------- > "hello"

which you can check by

assert( x is y )

or

assert( id( x ) == id( y ) )

and which becomes essential to understand when that object is mutable...

Like:

x = [1, 2, 3, 4]
y = "hello"

y = x
y.append( 5 )

print( x )

You want us to accept that the values of x and y are some mysterious
pointer entities rather than the integer object 5 and the string object
"hello".

The basics of pointers are simple.

You can copy pointers (assignment, argument), and you can check for equality
(is), and you can refer to the object that's pointed to (attribute access,
indexing, operators). And in CPython you can even obtain the pointer value as an
integer via id().

So there's nothing mysterious.

In particular

x = [1, 2, 3, 4]
y = x

does not copy the object value, it only copies the pointer.

That also matters for e.g.

x = 10000000*"A"
y = x

And aliasing, like in the last three examples above, is pretty difficult to
understand without a pointer view of things.

And if aliasing is not understood, then forever stranded at beginner's level.

At the point that your explanation depends on the reader understanding
that the value of a variable x is not actually the thing that they assign
to x, but some mysterious, invisible entity that exists entirely inside
the implementation where the user can never reach, you probably should
rethink your attachment to that explanation. No wonder so many Java
programmers are still confused by it.

Thanks for thinking about my writings.

As it happens I've already written about pointers in chapter 2, although not
mentioning the word "pointer".

I made do with the term "reference", because in Python there's not anything else
(in particular there's no pass by reference) that could cause confusion.

However, that cop-out (is that the right term?) wouldn't work for text based on
a language like C++, which has another kind of reference, or for that matter C#
which is like Python and Java except that C# also has pass by reference...

Some mixed feedbacks on that writing, but it's section 2.6.7 "References &
automatic garbage collection" in ch 2 "Basic concepts" at <url:
http://tinyurl.com/programmingbookP3> (I hope I typed the URL correctly).

It might help your case if we had a word for the thing that is actually
assigned to the variable. In plain English that is "value", but you want
to use that for the pointer to the thing-that-we-otherwise-would-call-
value, which leaves us no simple way to talk about the int 5 and string
"hello".

There are two values: the pointer value, and the object value.

In CPython:

More simply, there's the pointer and there's the object pointed to.

Or, in the not-very-general-but-I-think-works-in-Python terminology that I used
in 2.6.7, there's the reference and there's the object.

So the thing that's actually assigned to a variable is in language-independent
terminology a "pointer" (or pointer value), although that doesn't mean C or
Pascal or whatever specific language pointer but just a copyable object
reference, and perhaps in Python-specific terminology it's just a "reference".

I don't know better terms...


Cheers,

- Alf

 

[Steve Holden]

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

Stephen Hansen wrote:
[...]

P.S. I couldn't resist.

And here I was, sitting on my hands ... but someone was wrong on the
Internet, so D'Aprano had to put them right. Your fatal weakness.

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


This is getting out of hand.

First, someone thought I was you.

Now you think I'm D'Aprano.

I'm just gonna go by Bob for now on.

Sorry about that, Bob. But you have to admit your pedantry was rather
D'Aprano-like (I have these feeling I just insulted you both with one
sentence).

regards
Steve