What other languages use the same data model as Python?

[Grant Edwards]

Some would argue that C is actually better than assembler these
days, because modern architectures are so freaking complicated
that it takes a computer to figure out the best instruction
sequence. :-(

Been there, done that.

Many years ago, it took me more than a week (and required the help of
an ARM instruction set guru) to come up with an assembly language IP
checksum routine for the ARM that out-performed the somewhat naive
NetBSD "C" version. When we switched to the FreeBSD stack (and a
newer compiler) a few years later, my assembly code got tossed out
because was no longer any faster than the C version.

 

[Roy Smith]

That's what I was trying to say, but probably not as clearly. The "&"
operatore returnas a _value_ that the OP passes _by_value_ to a
function. That function then uses the "*" operator to use that value
to access some data.

Then, of course, there's references in C++. I think it's fair to call
the following "call by reference" in the sense we're talking about it
here.

void f(int& i) {
i = 5;
}
int i = 42;
f(i);

Of course, C++ lets you go off the deep end with abominations like
references to pointers. Come to think of it, C++ let's you go off the
deep end in so many ways...

 

[Grant Edwards]

Actually, this is incorrect. Most processors these days are hybrids
between that and either the Harvard or Modified Harvard architecture:

http://en.wikipedia.org/wiki/Modified_Harvard_architecture
http://en.wikipedia.org/wiki/Harvard_architecture
http://en.wikipedia.org/wiki/Von_Neumann_architecture

And a lot of the are still full-up Harvard architecture (e.g. the
entire Atmel AVR family and Intel 8051 family for example).

 

[harrismh777]

You should read Paul Graham on the Blub Paradox:

http://www.paulgraham.com/avg.html

Excellent-! ... thanks, fun article.


.... where is that lisp manual anyway? ... oh, yeah, emacs!

 

[Roy Smith]

C is better described as a high-level assembler, or a low-level language.
It is too close to the hardware to describe it as high-level, it has no
memory management, few data abstractions, and little protection.

+1

I (and most people who really know C and the specific hardware
architecture they're working on) should be able to look at a C program
and (modulo optimization) pretty much be able to write down the
generated assembler by hand. In fact, I used to do exactly that. I was
once working on M-6800 hardware (8/16-bit microprocessor). I used to
write out procedures in C, then hand-compile it into assembler code (and
leave the C code as a comment). I wasn't a true masochist, however. I
did let an assembler convert it to hex for me before I keyed it in

On the other hand, trying to do that for something like C++ is damn near
impossible. There's too much stuff that happens by magic. Creation
(and destruction) of temporary objects. Exception handling. RTTI. Not
to mention truly black magic like template expansion.

 

[Steven D'Aprano]

True enough. If I used Jython, I would want to take a look at those
sources... as well as the Java sources... which were wrtten in, um, C.

No, Java sources are written in Java. That's why they're *Java* sources.

Perhaps you mean that the Java compiler is written in C? Highly unlikely:
Java compilers have been self-hosting for many years now.

http://en.wikipedia.org/wiki/Self-hosting

 

[Steven D'Aprano]

However, I hope we can all agree that pass-by-pointer shares certain
features with both pass-by-value and pass-by-reference, and there are
perfectly reasonable arguments for lumping it in either category, yes?

*cries*

Please don't invent another "pass by foo" term!!!!

Seriously though, "pass by foo" refers to what the compiler or
interpreter does when you, the coder, call a function with some variable,
say, x:

f(x)

It is not referring to what you, the coder, does when you want to pass an
indirect reference of some sort to a chunk of data to some function. In
many languages, you would use a pointer, and write the function call
something like this:

f(^x)

(using Pascal's up-arrow notation for "pointer to").

Such "pass by pointer" is a tactic used by the coder, as opposed to a
language feature.

I believe this distinction between what the compiler does, and what the
coder does, is at the heart of much confusion. Pointers that are passed
as arguments are themselves data, just as much as ints or floats, or (in
languages that have first-class functions) functions.

 

[Neil Cerutti]

Of course, C++ lets you go off the deep end with abominations
like references to pointers. Come to think of it, C++ let's
you go off the deep end in so many ways...

But you can do some really cool stuff in the deep end.

 

[Steven D'Aprano]

I give up. You don't seem to understand the C language defintion or
what is commonly meant by "pass by reference".

In fairness, he's not the only one. M Harris has twice now linked to an
IBM site that describes pass-by-reference in C in terms of passing a
pointer to the argument you want as the argument. Admittedly, doing so
gives you almost the same behaviour, except that you have to dereference
the pointers yourself.

That's a pretty big difference though, and gets to the core of the
argument: it's a bit like arguing that manual cars are fitted with
exactly the same automatic transmission as auto cars, it's just that you
have to engage the clutch and shift gears yourself.

 

[Steven D'Aprano]

No, I explained Python in terms of pointers/reference.

Python has no pointers or references unless you simulate them yourself
using other data types.

They exist as implementation details of the Python virtual machine, which
is at least two levels below that of Python code. The first is the byte
code which runs in the virtual machine; the second is the code in the VM.

 

[Roy Smith]

But you can do some really cool stuff in the deep end.

"Hey, let's override operator,() and have some fun"

 

[Mel]

Some day, we'll be using quantum computers without memory addresses, [ ... ] it will still be possible to
represent data indirectly via *some* mechanism.

Cool! Pass-by-coincidence! And Python 3 already has dibs on the
'nonlocal' keyword!

Mel.

 

[John Nagle]

That wouldn't work for tuples, which can contain references
to other objects that are not immutable.

Such tuples are still identical, even if they
contain identical references to immutable objects.

John Nagle

 

[Steven D'Aprano]

Mu (ç„¡).

‘x’ is a name. Names are bound to values. Talk of “variable†only
confuses the issue because of the baggage carried with that term.

Yes, good point. Consider me chastised, because I actually knew that.
It's just that the term "variable" is so useful and so familiar that it's
easy to use it even for languages that don't have variables in the C/
Pascal/Fortran/etc sense.

But the data model of Python doesn't fit well with the ideas that the
term “variable†connotes for most programmers: a box, perhaps of a rigid
shape (data type) or not, which is labelled ‘x’ and nothing else. For
another variable to have an equal value, that value needs to be copied
and put in a separate box; or perhaps some special reference to the
original needs to be made and placed in a box.

Saying “variable†and “has the value†just invites baggage needlessly,
and creates many assumptions about Python's data model which has to be
un-done, often after much false mental scaffolding has been built on
them by the newbie and needs to be dismantled carefully.

I've quoted your two paragraphs because I think they're very important,
not because I intend arguing. Possibly a first for me

However....

Python isn't pass by anything. Nothing gets copied, nothing gets passed;
when a function is called with an object as a parameter, the object
stays put, and simply gets a new temporary name bound to it for the
function's use.

This, however, is incorrect. "Passing" in this sense refers to calling
the function with an argument, hence "pass by..." and "call by..." are
synonyms. The mechanics of how the compiler or interpreter makes
arguments available to functions has real consequences at the language
level: the calling strategy used by the compiler effects the language
semantics.

Juliet's point stands, though: they would still smell as sweet, and the
term you describe would be unlikely to catch on since it doesn't
describe them well at all.

Perhaps a counter-example is that of the tomato, which never took off as
a food in Europe until people stopped calling them "love apples", and
thinking that they were deadly poison.

Or Chinese Gooseberries, better known by the name thought up by a
marketing firm, "kiwi fruit".

 

[harrismh777]

Cool! Pass-by-coincidence! And Python 3 already has dibs on the
'nonlocal' keyword!

I was thinking pass-by-osmosis....

 

[John Nagle]

That's close to the right answer.

`is` is supposed to be a *fast* operator, not even slower than equality
testing.

That's an implementation problem. Those are cheap tests at the
machine code level. An efficient test looks like this:

def istest(a, b) :
if id(a) == id(b) : # the cheap address test
return(True)
if type(x) != type(y) : # cheap binary comparison
return(False)
if mutable(x) : # the interpreter knows this
return(False)
return(x == y) # equality test for mutables

Probably about 12 machine instructions, and the full "==" test
is only reached for cases in which "is" now produces wrong answers.

It's encouraging that a Google code search finds no matches of

if .* is \"
or
if .* is 1

in Python code.

John Nagle

 

[harrismh777]

In fairness, he's not the only one. M Harris has twice now linked to an
IBM site that describes pass-by-reference in C in terms of passing a
pointer to the argument you want as the argument. Admittedly, doing so
gives you almost the same behaviour, except that you have to dereference
the pointers yourself.

That's a pretty big difference though, and gets to the core of the
argument: it's a bit like arguing that manual cars are fitted with
exactly the same automatic transmission as auto cars, it's just that you
have to engage the clutch and shift gears yourself.

.... and actually, if you feel it just right and you have just the right
synchro-mesh setup, you can slide from 3rd into 4th without every
touching the clutch peddle... and if that isn't automatic, I don't know
what is.... man those were the days... now I just press a button that
says, "Auto 4-wheel Lock", set the gps, and take a nap...

 

[harrismh777]

I give up. You don't seem to understand the C language defintion or
what is commonly meant by "pass by reference".

ah, don't give up... here is a link that might help to clarify some of
these semantics... me thinks:

http://en.wikipedia.org/wiki/Pass_by_reference#Call_by_value




kind regards,
m harris

 

[Andreas Tawn]

Some day, we'll be using quantum computers without memory addresses,

[ ...
] it will still be possible to

represent data indirectly via *some* mechanism.

Cool! Pass-by-coincidence! And Python 3 already has dibs on the
'nonlocal' keyword!

Mel.

If True and False:
waveFunction.collapse(cat)


That's going to be fun ;o)

Cheers,

Drea

 

[Ian Kelly]

That wouldn't work for tuples, which can contain references
to other objects that are not immutable.

   Such tuples are still identical, even if they
contain identical references to immutable objects.

a = (1, 2, [3, 4, 5])
b = (1, 2, [3, 4, 5])
a == b True
a is b # Using the proposed definition True
a[0] is b[0] True
a[1] is b[1] True
a[2] is b[2] False
a[2].append(6)
a (1, 2, [3, 4, 5, 6])
b (1, 2, [3, 4, 5])
a == b False
a is b

False

Thus a and b cannot be used interchangeably even though "a is b"
originally returned True.