* Steve Holden:
Alf P. Steinbach wrote:
[snip]
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.
[snip]
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.
You go too far here. What you are referring to in your bizarrely
constructed definition above
No, it's not bizarre, it's the standard general language independent definition.
And since I'm referring to an external definition (Java) it's not mine, either.
:-)
as a pointer does not allow you to access
the value that is "pointed to". So I fail to see why you feel its its
introduction is necessary.
Python provides a number of ways to access the object pointed to.
Attribute access, indexing, and operators access the objects pointed to.
For example,
x = s[0]
accesses the object that s points (refers) to.
While 'is', 'id' and assignment operate on the pointers (references) themselves.
So there's one set of language features that operate on pointers, and one set of
language features that operate on the pointed to objects. This is so also in
Java and C#. For example.
Whether in CPython, Jython or IronPython the value returned by calling
id(x) (whether x is a literal, a simple name or a more complex
expression) is absolutely no use as an accessor: it does not give you
access to the referenced value.
Yes, the id does not give you access to the referenced object.
If you disagree, please write (in any implementation you like: it need
not even be portable, though I can't imagine why ti wouldn't be) a
Python function which takes an id() value as its argument and returns
the value for which the id() value was provided.
No, I don't disagree with that.
It would be excessively inefficient to do, involving enumeration of all objects.
So in your world it's unnecessary for pointers to point to anything (or
references to refer to something)? For someone who cheerfully admits to
being wrong from time to time (an admirable characteristic) you are
certainly difficult to convince on this point. One wonders what further
hand-waving will follow.
He he, "further" handwaiving: you're good at unsubstantiated allegations.
I generally strive to provide concrete examples, and you know it.
Anywyay, treating the first sentence as a genuine question: in the most likely
interpretation it seems that you're conflating id's with pointers. An id() value
uniquely represents a pointer (i.e., the identity of the object pointed to). It
is not itself a pointer since it lack any pointer semantics.
For a less likely more technical interpretation, as far as I know in Python
there's just one case of a pointer that does not point to anything, namely as
exemplified by
def foo():
print( x )
x = "whatever"
The Java equivalent would say "NullPointerException", in Python it says
something like "unbound". Which means the same.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
