On 23/07/13 18:17, Jim Mooney wrote:
On 23 July 2013 00:40, Steven D'Aprano <st...@pearwood.info> wrote:
No no no, a thousand times no!!! IDs are just numeric IDs, that is all,
like your social security number or driver's licence number. Don't think of
them as having any meaning at all, except that they are unique during the
lifetime of the object.
Okay, ID stands for a location fixed until the object disappears, but we
don't know where that location is.
No, it does not stand for a location. It is an identification number, that is
all.
In CPython, every value (lists, strings, integers, custom classes) are objects
which exist in one location until destroyed. In Jython and IronPython, values
are objects which can move from location to location, in order to free up
memory for new objects. In PyPy, not only can objects move, but they can also
be invisibly turned into low-level data structures for efficient processing. So
in CPython, Jython and IronPython, an object's identity is fixed. In PyPy,
object identity is an illusion, and according to the PyPy developers, keeping
that illusion working requires a lot of effort.
But what about object offsets from self?
That's always zero, since self is the object :-)
You can read up about the implementation of CPython here:
http://docs.python.org/2/c-api/
but this describes only the C interface, not the concrete implementation. For
that you pretty much have to read the source code. The C source code.
Is the beginning of self.spam always the same distance from the beginning
of self.eggs? Or can I just forget the hard ground of assembler-metaphors
entirely as I float off into abstractville? I guess the fixed lengths I
kept getting on re-runs were coincidental but not to be relied on.
Understanding a little of the concrete implementation details will help you
understand some of Python's design, and its limitations. But apart from that,
it's not necessary, and sometimes it is actually counter-productive. Thinking
in terms of low-level data can lead you wrong. For instance, when working in
low-level languages, it is normal to write code to minimize moving data from
place to place. For example, when sorting in C or assembly, comparing two
values is cheap, but swapping them is expensive. In Python it is the opposite:
swapping two values in a list just requires swapping two pointers, which is
cheap, but the comparison is quite expensive and could call arbitrary user code.
In CPython, objects are implemented in C, and are a block of memory that
contains various fields, and potentially pointers to other objects. The nature
of those fields will depend on which type of object they are.
In Jython, objects are implemented in Java, and in IronPython they are
implemented in C#, but otherwise are similar. But the layout of the fields will
be different, and the fields themselves, except perhaps by accident.
In PyPy, objects are implemented in RPython, a restricted and simplified
version of Python, which is then automatically translated by the optimizing
compiler into some low-level data structure behind the scenes.
Since Python is defined by its behaviour, not any sort of concrete implementation, in
principle one could invent a "Python Engine", like Babbage's Difference Engine,
only thousands of times more complex, entirely out of clockwork. Or by water flowing
through pipes, or reproducing DNA in a test tube, or some exotic quantum field. Or simply
simulate a Python interpreter in your head, perhaps aided by pencil and paper.
--
Steven
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
