* Steven D'Aprano:
On Wed, 10 Feb 2010 23:02:27 +0100, Alf P. Steinbach wrote:
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.
Not in plain language. NullPointerException means that x is assigned to a
null pointer, and you have tried to follow that pointer. Unbound means
that x has nothing assigned to it.
No, it's the same.
String x;
somethingIDontRememberProbablyIo.println( x ) // Java equivalent
It's just different terminology, "NullPointerException" versus "unbound".
It's the same semantics.
Nothing substantial is changed by changing the Java message or changing the
Python message.
The word is just a word.
Semantically, the difference is
somewhat analogous to the situations:
"the president is dead, and a new president hasn't yet been appointed"
(the office of the president is currently assigned to a dead guy)
versus
"the king has dissolved parliament and with it the office of president"
(there is no president at all)
Now, of course we understand that in the implementation of CPython, local
variables are stored efficiently in slots in an array, and you can't have
empty slots: every address always has some bit pattern. It is very likely
that the CPython implementation uses a nil pointer to indicate an empty
slot just like Java does. The difference is that Java exposes that
implementation decision as part of the language specification, while
Python deliberately does not.
How a Python implementation implements local variables is irrelevant, except
that since references to local variables can be copied and *live on*, be used,
after a call, it has to work as if it uses implementation level pointers.
The notion of pointers (references) at the language level is not the same as the
notion of pointers at the implementation level.
This is the same as the notion of integers at the Python 3.x level (unbounded
values) is not the same as the notion of integers at the C or C# or Java level
(depending on the Python implementation, bounded values with wrap-around or
undefined behavior).
I.e. you're conflating two levels here.
You can perhaps more easily see that by considering an implementation of Python
in Python, using some computed counter as object id's. It doesn't change the
user view of copyable references. But it hides all that C pointer stuff two or
three abstraction levels down so that it becomes meaningless to talk about it.
It isn't an accident that the Python exception describes the *semantics*
of the error (x is not bound to any value) rather than the implementation
detail (the slot known as x has a nil pointer in it). Semantically, the
Python language treats the slot as empty and leaves the details of how
the implementation recognises empty slots as an implementation decision.
I'm just as interested by the implementation decisions made in CPython as
the next guy, but they don't effect the semantics of the high level
Python language.
Right.
Here is a thought experiment for you:
One can imagine an implementation of Python that eschews all pointers for
some scheme by which objects are cleverly copied and synchronized as
needed. Such an implementation would still be Python, but it would be
entirely pointer-free.
Uhm, bad example (it wouldn't work exactly as described), but concerning what I
think you're trying to /communicate/, that X at the Python level is not the same
as X at the implementation level, like, 'int' at the Python 3.x level is not
'int' in C, and like, "pointer" at the Python level is not "pointer" in C: yes.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
