Finding the instance reference of an object
steve at REMOVE-THIS-cybersource.com.au
Sun Oct 19 07:52:33 CEST 2008
On Fri, 17 Oct 2008 15:39:33 -0600, Joe Strout wrote:
> On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:
>>> And my real point is that this is exactly the same as in every other
>>> modern language.
>> No, it isn't. In many other languages (C, Pascal, etc.), a "variable"
>> is commonly thought of as a fixed location in memory into which one can
>> put values. Those values may be references to objects.
> Right, though not in languages like C and Pascal that don't HAVE the
> notion of objects. We really ought to stop bringing up those dinosaurs
> and instead compare Python to any modern OOP language.
You really should stop assuming that languages still in use are
"dinosaurs". There are many, many people whose understanding of such
terms as "call by value" or "variable" are based on C or Pascal or even
Besides, while the Pascal language itself doesn't have objects, plenty of
Pascal implementations do.
>> In Python, that's not how it works. There is no
>> "location in memory" that corresponds to a variable with a particular
>> name the way there is in C or Pascal or Fortran or many other
> No? Is there any way to prove that, without delving into the Python
> source itself?
>>> x = 1
>>> id(x) # a unique identifier, in CPython equal to its address
>>> x = 2
Notice that the address of x changes. Actually, that's a lie. The name
'x' doesn't have an address, except in the sense that the string 'x' must
occur somewhere in memory. But that's an unimportant implementation
detail. In reality, what we see is:
the object 1 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (1), which is 135536432;
the object 2 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (2), which is 135536420.
That's what is happening at the Python level of code. Anything else is
just implementation details.
> If not, then I think you're talking about an internal implementation
Namespaces aren't an internal implementation detail, they are fundamental
to how Python works.
>> All that exists in Python is a name->object mapping.
> And what does that name->object mapping consist of? At some level,
> there has to be a memory location that stores the reference to the
> object, right?
Who cares? That's the *wrong* level. At *some* level, everything is just
flipping electrons from one state to another, but I think even you would
object if I claimed that:
"All computer languages are call-by-flipping-electrons, with no
Somebody could implement a Python interpreter using literal post-it notes
for names and literal boxes for objects. The fact that our CPUs are
optimized for flipping bits instead of (say) water flowing through tubes,
or clockwork, or punching holes in paper tape, is irrelevant. When
discussing what Python code does, the right level is to discuss the
Python virtual machine, not the implementation of that VM.
If you want to discuss the deeper levels, it's perfectly acceptable to
say that the CPython implementation uses memory locations holding
pointers. But that's not *Python*, that's hidden detail that the Python
programmer can't reach.
>>> Nothing unusual here at all (except that some of us here seem to want
>>> to make up new terminology for standard behavior, perhaps in order to
>>> make Python seem more exotic).
>> That's because it is fundamentally different from what happens in
>> languages like C.
> What happens in a modern OOP language is just as fundamentally different
> (which is to say, not really very much) from what happens in C or
> FORTRAN or COBOL, too.
Which is why modern OOP languages like Python shouldn't use the same
terminology invented to describe what Fortran and Pascal do.
> If you make up new terms like "rebinds,"
This is not something that is just "made up", it is an actual description
of what the Python VM does.
> well, I guess at least that
> avoids giving the listener the wrong idea.
As opposed to call-by-value, call-by-reference, and "call-by-value-where-
the-value-is-the-reference", all of which do give the listener the wrong
> Instead it gives them no
> idea at all, which may be better, but not as good as giving them the
> right idea.
But it is the right idea. They just don't know what it means, because
they've been listening to people like you who insist on using Pascal
terminology with a definition unrecognizable to Pascal programmers. To an
ex-Pascal programmer like myself, when you talk about "call by value
where the value is a reference", it sounds to me as if you are insisting
that cars are ACTUALLY horse and buggies, where the horse is the engine,
why are we inventing new terms like 'automobile', that just confuses
> It still leaves them to investigate what actually happens,
> and ultimately they will find that the parameters are always passed by
> value in Python.
But they aren't. When you call a function, the arguments are not copied
before being passed to the function.
> May as well save them the trouble and point that out
> up front.
Well, sure, if you want to be misleading and confusing.
> And how many recovering FORTRAN or C programmers do we get around here,
It's not just people who have programmed Pascal, but those whose
understanding of CBV and CBR have been shaped by ancient half-remembered
> Java is what they've been teaching in school for the last
> several years, and it was C++ for a good decade before that.
Have they really? Which school is that?
My company has hired a part-time young gun programmer. He's still at Uni,
doing Comp Sci, and has *far* wider IT experience than the average
programmer his age. His skills? PHP, Perl, C, oh and he's just starting
to learn C++ this semester.
There are plenty of programmers who have never been to university or
collage, and even some who have never learnt programming in school at
all. Believe it or not, it's not compulsory.
More information about the Python-list