* Duncan Booth:
"Alf P. Steinbach" <al...@start.no> wrote:
In CPython objects once created remain in the same memory location
(and their id is their address). Compare that to IronPython where the
objects themselves can move around in memory so they have no fixed
address. Try comparing the IronPython implementation to C pointers
and you'll cause a lot of confusion. e.g. someone might think the
id() value is in some way related to an address.
Did you /read/ what you quoted?
Ruby implements integers without using any pointers at all: there's
nothing in the Python specification which prevents a Python
implementation doing the same for small integers, in fact I believe
it has been tried but wasn't found to improve performance.
All theree of your points about Python are wrong; I don't know about
the Ruby point.
Would you care to expand upon your claim that my three points about Python
are wrong?
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.
Are you saying that CPyhton objects move around, or that
IronPython objects are fixed to a single memory location or that their id
is related to their address?
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().
Clue here:
IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
x = 42
id(x)
43
y = 43
id(y)
44
z = "whatever"
id(z)
45
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.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
