Terminology: "reference" versus "pointer"
rurpy at yahoo.com
rurpy at yahoo.com
Sun Sep 13 02:25:15 CEST 2015
On 09/12/2015 05:39 PM, Rustom Mody wrote:
> On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru... at yahoo.com wrote:
>> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
>>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>>>> The question is whether what "pointer" means in languages that use the
>>>> word is*so* different than its meaning in the Python sense
>>> I can't find a single reference to pointer in the python docs outside
>>> of ctypes. What is its python sense?
>> I should have said "proposed sense" (except I don't really mean
>> proposed as in "let's change all the docs" but as "let's stop the
>> hissy-fits when someone uses the term"), i.e. the way I, I think
>> random832, and others use it re python. Sorry, I see in retrospect
>> my phrasing could be confusing.
> Here is my post a little way up:
> On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:
>> Insisting that Python has pointers is like insisting that you use a text
>> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
>> bits on the screen flip from black to white, these bits flip from white to
>> black, and these stay the same."
> This is from the docs
> Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.
> CPython implementation detail: This is the address of the object in memory.
> which may be summarized as:
> 1. Steven (quoting Online dictionary): Pointer = Address
> 2. Steven: "Python has pointers" is ridiculous
> 3. Python docs: id returns an address in (C)Python
> To which we have Chris saying CPython ≠ Python
> Which reminds me of another definition
> Fig-Leaf: A device for converting poor porn into high art
> Even in languages like C with an ISO standard adhering to the standard is
> academic (gcc's switch is --pedantic) and it is in practice major
> implementations like gcc and MSC that define and push the standard.
> In python, CPython is the standard and other implementations can lay claim to
> being 'python' to the extent that they adhere to the standard.
> Or have I missed some ISO-ization?
I have to agree with Steven and Chris here. Among other reasons because
although id() allows you to determine if two objects are the same object,
you can't dereference it to get any access to the object. So id() certainly
doesn't give you something I would call a pointer. And though you are right
about cpython's preeminent position, I don't think one can use that to make
an argument about python-the-language unless it can be shown that implementing
it in some other way would be very difficult.
More information about the Python-list