Python's Reference And Internal Model Of Computing Languages

[Xah Lee]

just wrote this essay. Comment & feedback very welcome.

Python's Reference And Internal Model Of Computing Languages

Xah Lee, 2010-02-02

In Python, there are 2 ways to clear a hash: “myHash = {}†and
“myHash.clear()â€. What is the difference?
↓

The difference is that “myHash={}†simply creates a new empty hash and
assigns to myHash, while “myHash.clear()†actually clear the hash the
myHash is pointing to.

What does that mean?? Here's a code that illustrates:

# python
# 2 ways to clear hash and their difference
aa = {'a':3, 'b':4}
bb = aa
aa = {}
print bb # prints {'a': 3, 'b': 4}

aa = {'a':3, 'b':4}
bb = aa
aa.clear()
print bb # prints {}

This is like this because of the “reference†concept. The opposite
alternative, is that everything is a copy, for example in most
functional langs. (with respect to programer-visible behavior, not how
it is implemented)

From the aspect of the relation of the language source code to the
program behavior by the source code, this “referenceâ€-induced behavior
is similar to dynamic scope vs lexicol scope. The former being un-
intuitive and hard to understand the latter more intuitive and clear.
The former requires the lang to have a internal model of the language,
the latter more correspond to source code WYSIWYG. The former being
easy to implement and is in early langs, the latter being more popular
today.

As with many languages that have concept of references, or pointers,
this is a complexity that hampers programing progress. The concept of
using some sort of “reference†as part of the language is due to
implementation efficiency. Starting with C and others in 1960s up to
1990s. But as time went on, this concept in computer languages are
gradually disappearing, as they should.

Other langs that have this “reference†concept as ESSENTIAL part of
the semantic of the language, includes: C, C++, Java, Perl, Common
Lisp. (of course, each using different terminologies, and each lang
faction will gouge the other faction's eyes out about what is the true
meaning of terms like “referenceâ€, “objectâ€, “list/sequence/vector/
array/hashâ€, and absolutely pretend other meanings do not exist.
(partly due to, their ignorance of langs other than their own, partly,
due to male power struggle nature.))

Languages that do not have any “reference†or “objectâ€, or otherwise
does not require the programer to have some internal model of source
code, are: Mathematica, JavaScript, PHP. (others may include TCL,
possibly assembly langs.)

For some detail on this, see: Jargons And High Level Languages and
Hardware Modeled Computer Languages.

---------------------------

(perm url of this essay can be found on my website.)

Xah
∑ http://xahlee.org/

☄

 

[Ryan Kelly]

I know, I know, do not feed the trolls. But this is just so *wrong*
that I can't help myself.

In Python, there are 2 ways to clear a hash:

No, no there's not. There's one way to clear a hash and there's one way
to assign a new object to a variable.

“myHash = {}†and
“myHash.clear()â€. What is the difference?
The difference is that “myHash={}†simply creates a new empty hash and
assigns to myHash, while “myHash.clear()†actually clear the hash the
myHash is pointing to.

What does that mean?? Here's a code that illustrates:

# python
# 2 ways to clear hash and their difference
aa = {'a':3, 'b':4}
bb = aa
aa = {}
print bb # prints {'a': 3, 'b': 4}

aa = {'a':3, 'b':4}
bb = aa
aa.clear()
print bb # prints {}

This is like this because of the “reference†concept.

....snip inane babble...

Languages that do not have any “reference†or “objectâ€, or otherwise
does not require the programer to have some internal model of source
code, are: Mathematica, JavaScript, PHP. (others may include TCL,
possibly assembly langs.)

Just so we're all clear exactly how much thought has gone into this
little rant, here's a transcript from a JavaScript session:

var aa = {};
var bb = aa;
aa.hello = "world";
alert(bb.hello) --> "world"
delete bb.hello
alert(aa.hello) --> "undefined"

OMFG, references!!

Come to think of it, the JavaScript and Python object models are really
very similar. I'm genuinely curious now - what little sprinkle of magic
fairy dust has earned JavaScript objects the Xah Lee seal of approval
while Python objects miss out?


Ryan




--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
(e-mail address removed) | http://www.rfk.id.au/ramblings/gpg/ for details


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkto458ACgkQfI5S64uP50qkewCgkxJlRvmtWSBJ1tVP8RqEU2LE
SpYAoI9KoOkQDG8m6oYBzOmmFTyqm8zy
=z4im
-----END PGP SIGNATURE-----

 

[Paul Rubin]

I know, I know, do not feed the trolls. But this is just so *wrong*
that I can't help myself.

See: http://xkcd.com/386/

 

[Xah Lee]

I know, I know, do not feed the trolls.  But this is just so *wrong*
that I can't help myself.


No, no there's not.  There's one way to clear a hash and there's one way
to assign a new object to a variable.










...snip inane babble...


Just so we're all clear exactly how much thought has gone into this
little rant, here's a transcript from a JavaScript session:

  var aa = {};
  var bb = aa;
  aa.hello = "world";
  alert(bb.hello)  -->  "world"
  delete bb.hello
  alert(aa.hello)  -->  "undefined"

OMFG, references!!

Come to think of it, the JavaScript and Python object models are really
very similar.  I'm genuinely curious now - what little sprinkle of magic
fairy dust has earned JavaScript objects the Xah Lee seal of approval
while Python objects miss out?

Thanks. You are right. I think i put JavaScript there without much
thinking.

Xah

 

[Gib Bogle]

See: http://xkcd.com/386/

 

[David Thole]

I read this....and am a tiny bit confused about the actual problem.

It's not exactly complex to realize that something like:
a = b = array
that a and b both point to the array.

Logically speaking, I'm not sure how one could assume that the same
assignment would yield a and b point to the same duplicate array. If
that was the case, why not do:
a = array..
b = array..

I know with what you were complaining about a few days ago, .clear makes
perfect sense. If a and b point to the same array, clear should clear
both arrays. Again, if you didn't want that to happen, create a
duplicate array.

Personally I feel that this complexity doesn't hamper programming
process, and yes while its good for efficiency it also just makes sense.

Also, I wouldn't look at PHP on the right way to do something
programming wise. I have ~5 years experience in this language, and I
dislike it a whole lot. There's a lot of things it should do right that
it doesn't out of convenience.

-David
www.thedarktrumpet.com

 

[Jürgen Exner]

I read this....and am a tiny bit confused about the actual problem.

It's not exactly complex to realize that something like:
a = b = array
that a and b both point to the array.

???
What are you talking about? First of all you should post actual code,
not pseudo-code because pseudo-code leads to misunderstandings. Did you
mean
@a = @b = @array

Second what do you mean by "pointing"? That is a very ambiguous term. if
you do the assignment as written above then @a and @b will be _copies_
of @array. If you want two additional references to the same array
insted then you have to create that reference first and assign that
reference to $a and $b instead of copying the array, see "perldoc
perlref" for details. And remember, references are scalars, no matter if
they reference other scalars or arrays.

Logically speaking, I'm not sure how one could assume that the same
assignment would yield a and b point to the same duplicate array. If

Now what? The same array or a duplicate array? Two very different and
mutually exclusive things.

that was the case, why not do:
a = array..
b = array..

Which, after correcting the obvious syntax errors is the same as the
code above.

I know with what you were complaining about a few days ago, .clear makes
perfect sense. If a and b point to the same array, clear should clear

They don't point, they are copies. And what do you mean by "clear"?

both arrays. Again, if you didn't want that to happen, create a
duplicate array.

But that is what that code above does. If you want references then
create references.

jue

 

[Steven D'Aprano]

I read this....and am a tiny bit confused about the actual problem.

It's not exactly complex to realize that something like: a = b = array
that a and b both point to the array.

Logically speaking, I'm not sure how one could assume that the same
assignment would yield a and b point to the same duplicate array.

It's an easy mistake to make, if you don't understand Python's object
model:

a = b = 2
a += 1
a, b (3, 2)
a = b = [2]
a[0] += 1
a, b

([3], [3])

For the non-Python coders reading, the difference is that ints are
immutable, and hence a += 1 assigns a to a new int, leaving b untouched,
but lists are mutable, hence a[0] += 1 mutates the list which both a and
b refer to. This is a Good Thing, but it is one of the things which give
newcomers some trouble.