Re: Terminology: "reference" versus "pointer"

On Wed, Sep 16, 2015 at 6:24 PM, Ben Finney wrote: > Chris Angelico writes: > >> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing >> wrote: >> > This suggests an alternative model for Python computation. All data >> > is

Re: Terminology: "reference" versus "pointer"

On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing wrote: > Emile van Sebille wrote: > >> Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs, > > > The real question is, if you kill Schroedinger's cat, does > Heisenberg's cat die too? If so, then either they're the >

Re: Terminology: "reference" versus "pointer"

Chris Angelico writes: > On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing > wrote: > > This suggests an alternative model for Python computation. All data > > is represented by cats. A variable is a box containing a cat. > > Assignment replaces one

Re: Terminology: "reference" versus "pointer"

Emile van Sebille wrote: Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs, The real question is, if you kill Schroedinger's cat, does Heisenberg's cat die too? If so, then either they're the same cat, or they're two entangled cats. This suggests an alternative model for Python

Re: Terminology: "reference" versus "pointer"

On Tue, 15 Sep 2015 04:02 am, Random832 wrote: > The point is that with immutable objects no-one cares if they are three > objects with the same value, or three references to the same object. Well, you might care... a = (1,)*(10**12) b = (1,)*(10**12) c = (1,)*(10**12) Each of those tuples

Re: Terminology: "reference" versus "pointer"

On Tue, 15 Sep 2015 03:34 am, Random832 wrote: > On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote: >> On Tue, 15 Sep 2015 01:10 am, Random832 wrote: >> > That's not true in CPython. In fact, the range object in python >> > contains *four* reference boxes - one more for length. >> >> I

Re: Terminology: "reference" versus "pointer"

Random832 writes: ... > Why can't it describe range(1)? A range object in my model would include > the start, stop, and step; _not_ the contents of what you would get by > iterating over it; since that's not part of the physical structure of > the object, but the

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015, at 10:48, Akira Li wrote: > start, stop, step attributes (corresponding Python ints) may not exist > ("the objects we've talking about have never been created") until you > request them explicitly. That's not true in CPython. In fact, the range object in python contains

Re: Terminology: "reference" versus "pointer"

On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote: > Steven D'Aprano writes: > >> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: >>> Look at the last example: >>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 >> >> >> I'm afraid that page is broken in my

Re: Terminology: "reference" versus "pointer"

On Tue, 15 Sep 2015 01:10 am, Random832 wrote: > On Mon, Sep 14, 2015, at 10:48, Akira Li wrote: >> start, stop, step attributes (corresponding Python ints) may not exist >> ("the objects we've talking about have never been created") until you >> request them explicitly. > > That's not true in

Re: Terminology: "reference" versus "pointer"

Steven D'Aprano writes: > On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote: > >> Steven D'Aprano writes: >> >>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: Look at the last example:

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote: > On Tue, 15 Sep 2015 01:10 am, Random832 wrote: > > That's not true in CPython. In fact, the range object in python contains > > *four* reference boxes - one more for length. > > I really don't see why any of this is relevant to the business

Re: Terminology: "reference" versus "pointer"

Ned Batchelder writes: > On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote: >> Ned Batchelder writes: >> ... >> > What do you feel is missing from Steven's diagram? >> >> I don't feel anything missing because I don't expect the

Re: Terminology: "reference" versus "pointer"

On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote: > Ned Batchelder writes: > ... > > What do you feel is missing from Steven's diagram? > > I don't feel anything missing because I don't expect the model to be > more detailed. Akira, you said, "neither

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015, at 19:17, Akira Li wrote: > "do not physically exist" does not make sense. Objects are *never* > destroyed explicitly in Python (you can only make them > *unreachable*). But the objects we've talking about have never been created, because the __getitem__ method has not been

Re: Terminology: "reference" versus "pointer"

On Tue, Sep 15, 2015 at 3:51 AM, Emile van Sebille wrote: > Actually, boxes with integers in them isn't the appropriate analogy. > Consider the naming of cats. My cat is known to me as Paddy. My next door > neighbor sometimes feeds her and is known to her as Stripes. The cat

Re: Terminology: "reference" versus "pointer"

On Monday, September 14, 2015 at 1:26:39 PM UTC-4, Akira Li wrote: > My point is that neither models are detailed enough to describe > meaningfully the behavior of Python code in the general case. This is of course true, because a model is never detailed enough to fully describe the real thing.

Re: Terminology: "reference" versus "pointer"

Random832 writes: > On Mon, Sep 14, 2015, at 10:48, Akira Li wrote: >> start, stop, step attributes (corresponding Python ints) may not exist >> ("the objects we've talking about have never been created") until you >> request them explicitly. > > That's not true in

Re: Terminology: "reference" versus "pointer"

Random832 writes: > On Mon, Sep 14, 2015, at 13:45, Akira Li wrote: >>[box + arrow pointing to] + object == parcel tag + object > > The problem is that if there are multiple namespaces, or if you've also > got to include references from within other objects such as

Re: Terminology: "reference" versus "pointer"

On 9/14/2015 10:34 AM, Random832 wrote: Personally I think it's a bit silly to insist on a diagram model where a box with an arrow in it pointing at an int object can't be represented by a box with an integer in it (where 'int' is any immutable type - string, tuple, even range), but people

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015, at 13:45, Akira Li wrote: >[box + arrow pointing to] + object == parcel tag + object The problem is that if there are multiple namespaces, or if you've also got to include references from within other objects such as list, then you've got to write all that somehow on the

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015, at 13:51, Emile van Sebille wrote: > Actually, boxes with integers in them isn't the appropriate analogy. > Consider the naming of cats. My cat is known to me as Paddy. My next > door neighbor sometimes feeds her and is known to her as Stripes. The > cat also is known

Re: Terminology: "reference" versus "pointer"

Ned Batchelder writes: ... > What do you feel is missing from Steven's diagram? I don't feel anything missing because I don't expect the model to be more detailed. -- https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

Random832 writes: > Jussi Piitulainen writes: >> I think the best way is to say that a[0] and a[1] are the same >> object, while b[0] and b[1] are different objects. > > Sure, you can *say* that. But how do you draw it on a diagram with > sticky notes or parcel tags or whatever? I prefer to

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 10:50 pm, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote: ... ^ > But as I said to Rurpy, Er, that would be you. Editing fail. Sorry about that. -- Steven --

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015 at 1:31 AM, rurpy--- via Python-list wrote: > Ben, > > If the troll being taunted here is referring to me, I suggest > you review my posts in this thread, You've said in the past > that you don't read posts from Google Groups (that's fine, > your

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote: > On 09/12/2015 10:32 AM, Steven D'Aprano wrote: >> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >>[...] >> Computer science and IT is *dominated* by a single usage for "pointer" -- >> it's an abstract memory address. The fundamental

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 08:42 PM, Ben Finney wrote: > Michael Torrie writes: >> On 09/12/2015 08:22 PM, Mark Lawrence wrote: >>> You appear to have the same level of knowledge of Python internals as >>> the RUE has of the Python 3.3+ FSR unicode implementation. Let's have >>> some

Re: Terminology: "reference" versus "pointer"

Random832 writes: > Akira Li <4kir4...@gmail.com> writes: >>Rustom Mody writes: >>> viz. I have two variables (or names!) say a and b which look the same >> a >>> [[1,2],[1,2]] >> b >>> [[1,2],[1,2]] >>> And yet doing >> a[0][0] =

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015 at 4:04 AM, Akira Li <4kir4...@gmail.com> wrote: >> (If I were drawing a picture rather than ASCII I'd add something to make >> it clear that the pairs shown are list objects Like, it's a circle with >> the word "list" and two pointer-boxes inside it.) > > "correct and

Re: Terminology: "reference" versus "pointer"

Akira Li <4kir4...@gmail.com> writes: > I'm not sure what "parcel tags" model is but if you mean these > pictures[1] than it works in this case as well as any other (take *a*, > *b* nametags, put them on the corresponding balloons that represents > list objects). > > The only names left are *a*

Re: Terminology: "reference" versus "pointer"

Chris Angelico writes: > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or > "Resident Unicode Expert". There has been a long-standing antagonism > between those two (which is completely understandable), and one which > often spills over into vitriolic

Re: Terminology: "reference" versus "pointer"

Chris Angelico writes: > On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote: >> If you mean this quote from [1]: >> >> Although we commonly refer to "variables" even in Python (because it's >> common terminology), we really mean "names" or "identifiers".

Re: Terminology: "reference" versus "pointer"

On 09/13/2015 06:50 AM, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote: >> On 09/12/2015 10:32 AM, Steven D'Aprano wrote: >>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >>> [...] >>> Computer science and IT is *dominated* by a single usage for "pointer" -- >>>

Re: Terminology: "reference" versus "pointer"

Random832 writes: > Akira Li <4kir4...@gmail.com> writes: >> I'm not sure what "parcel tags" model is but if you mean these >> pictures[1] than it works in this case as well as any other (take *a*, >> *b* nametags, put them on the corresponding balloons that represents >>

Re: Terminology: "reference" versus "pointer"

On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: > I don't see why the model that can't describe range(1) in Python 3 > pretends to be complete. Please explain. range(1) returns a range instance. What is hard about that? -- Steven -- https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

Chris Angelico writes: > On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote: >> Steven D'Aprano writes: >> >>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >>> I don't see why the model that can't describe range(1) in Python 3

Re: Terminology: "reference" versus "pointer"

On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: > Steven D'Aprano writes: > >> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >> >>> I don't see why the model that can't describe range(1) in Python 3 >>> pretends to be complete. >> >> >> Please explain. >> >> range(1) returns

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote: > If you mean this quote from [1]: > > Although we commonly refer to "variables" even in Python (because it's > common terminology), we really mean "names" or "identifiers". In > Python, "variables" are nametags for

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015 at 10:30 AM, Akira Li <4kir4...@gmail.com> wrote: > "Naming and binding" is the title from the Python language reference > https://docs.python.org/3/reference/executionmodel.html#naming-and-binding > > Otherwise, I agree with you ("name" is better here). Ah, gotcha. That's

Re: Terminology: "reference" versus "pointer"

Steven D'Aprano writes: > On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: > >> I don't see why the model that can't describe range(1) in Python 3 >> pretends to be complete. > > > Please explain. > > range(1) returns a range instance. What is hard about that? Look at the last

Re: Terminology: "reference" versus "pointer"

On Sunday, September 13, 2015 at 2:49:13 PM UTC-6, Ben Finney wrote: > Chris Angelico writes: > > > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or > > "Resident Unicode Expert". There has been a long-standing antagonism > > between those two (which is

Re: Terminology: "reference" versus "pointer"

On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote: > Steven D'Aprano writes: > >> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote: >> >>> I don't see why the model that can't describe range(1) in Python 3 >>> pretends to be complete. >> >> >> Please explain.

Re: Terminology: "reference" versus "pointer"

Steven D'Aprano writes: > On Mon, 14 Sep 2015 11:22 am, Akira Li wrote: >> Look at the last example: >> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704 > > > I'm afraid that page is broken in my browser. Can you not summarise, or link > to the specific

Re: Terminology: "reference" versus "pointer"

On 14/09/2015 02:34, rurpy--- via Python-list wrote: Goodbye, *plonk* -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing

Re: Terminology: "reference" versus "pointer"

On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: >> You've clearly committed to some ontology that just doesn't match the >> Python data model. > > How about lay-English ontology in which "point to" and "refer to" are

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote: > Frankly, I feel a little insulted by people who presume that having > learned what a pointer is in C, that my brain is so rigid that I must > necessarily think that pointer means exactly what pointer means in C > forever

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > Having programmed in C in the past, Well, there's your problem. Like BASIC before it, anyone who has learned C is mentally crippled for life as a programmer *wink* > the model of Python I eventually > developed is very much (I think,

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: > Rustom Mody writes: > > > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton > > wrote: > >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >> >How about lay-English ontology

Re: Terminology: "reference" versus "pointer"

Akira Li <4kir4...@gmail.com> writes: >Rustom Mody writes: >> viz. I have two variables (or names!) say a and b which look the same > a >> [[1,2],[1,2]] > b >> [[1,2],[1,2]] >> And yet doing > a[0][0] = "Oops!" >> gives a data structure one "Oops!" >> whereas

Re: Terminology: "reference" versus "pointer"

On 12/09/2015 23:34, rurpy--- via Python-list 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

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 10:32 AM, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: >[...] > Computer science and IT is *dominated* by a single usage for "pointer" -- > it's an abstract memory address. The fundamental characteristics of > pointers are: Just upthread, you claimed

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 9:39 AM, Rustom Mody wrote: > 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

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >> >How about lay-English ontology in which "point to" and "refer to" are fairly >> >synonymous? >>

Re: Terminology: "reference" versus "pointer"

On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@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

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list 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

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano wrote: > Note: when I write my own Python implementation, all IDs will be negative > odd numbers. When I build my own CPU architecture, all memory addresses will be negative odd numbers, so people think your Python uses

Re: Terminology: "reference" versus "pointer"

Jussi Piitulainen writes: > I think the best way is to say that a[0] and a[1] are the same object, > while b[0] and b[1] are different objects. Sure, you can *say* that. But how do you draw it on a diagram with sticky notes or parcel tags or whatever? --

Re: Terminology: "reference" versus "pointer"

Picking a post to respond to, more or less at random... On Saturday, September 12, 2015 at 9:14:00 AM UTC-6, Rustom Mody wrote: > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > > >How about

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 02:54 am, Rustom Mody wrote: > This is from the docs > https://docs.python.org/3/library/functions.html#id Yes, what of it? What point do you think you are making? > id(object) > > Return the "identity" of an object. This is an integer which is > guaranteed to be

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 03:12 am, Rustom Mody wrote: > Best I can see, the people frothing at the mouth that python has no > pointers are basically saying that "non-first-class" == "non-existent" Not at all. In Python, at least, all values are first-class, but that's not the case with all languages

Re: Terminology: "reference" versus "pointer"

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

Re: Terminology: "reference" versus "pointer"

On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody 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

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote: > Python values are not addresses. Python values are objects. Which means for example...??? Atoms? Stars? People? Countries? > Addresses, even when they exist, are not accessible in the Python language. And you

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 11:48 AM, Steven D'Aprano wrote: > On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote: > [...] >> the model of Python I eventually >> developed is very much (I think, haven't read the whole thread) like >> Random832's. I think of boxes (objects) with slots containing "pointers" >>

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: a > [[1,2],[1,2]] b > [[1,2],[1,2]] > And yet doing a[0][0] = "Oops!" > gives a data structure one "Oops!" > whereas doing it to b mysteriously gives 2 > > Best I can see you can only explain this > seemingly-similar-but-structurally-different > with

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: >> Rustom Mody writes: >> >> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton >> > wrote: >> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700,

Re: Terminology: "reference" versus "pointer"

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

Re: Terminology: “reference” versus “pointer”

On Sat, 12 Sep 2015 03:03 pm, Random832 wrote: > Yes I am. You're just making the implicit assumption that a "value" has > to be a number, and I was ignoring that assumption. The value is the > address of an object. The unknown, unknowable, and in fact possibly non-existent address of an object.

Re: Terminology: "reference" versus "pointer"

On 9/12/2015 9:54 AM, Rustom Mody wrote: On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: Anyway, maybe we do need a term to distinguish Python/C#/Java pointers from C/C++ pointers - maybe call it a "non-arithmetic"

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > > > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > >> You've clearly committed to some ontology that just doesn't match the > >>

Re: Terminology: “reference” versus “pointer”

On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > the key thing about it is you can't do pointer arithmetic on them to get > the object "next to" the one

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 06:02 PM, Ned Batchelder wrote: > On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > [...] > But in C, pointers mean more than that. You can perform arithmetic on > them, to access memory as a linearly addressed abstraction. Python has > nothing like this.

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 6:25:39 PM UTC-6, ru...@yahoo.com wrote: > On 09/12/2015 05:39 PM, Rustom Mody wrote: > [...] > > which may be summarized as: > > 1. Steven (quoting Online dictionary): Pointer = Address > > 2. Steven: "Python has pointers" is ridiculous > > 3. Python docs: id

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 05:14 PM, Mark Lawrence wrote: > On 12/09/2015 23:34, rurpy--- via Python-list 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

Re: Terminology: "reference" versus "pointer"

On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote: > In its implementation, CPython uses pointers. But if you say that Python > has pointers because CPython uses pointers, then you might as well say > that Python is statically typed because the CPython source has type >

Re: Terminology: "reference" versus "pointer"

Rustom Mody writes: > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > You've clearly committed to some ontology that just doesn't match > > the Python data model. > > How about lay-English ontology in which "point to" and "refer to" are

Re: Terminology: "reference" versus "pointer"

Michael Torrie writes: > On 09/12/2015 08:22 PM, Mark Lawrence wrote: > > You appear to have the same level of knowledge of Python internals as > > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > > some fun, is Python pass by value or pass by

Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 07:10 am, Random832 wrote: > Jussi Piitulainen writes: >> I think the best way is to say that a[0] and a[1] are the same object, >> while b[0] and b[1] are different objects. > > Sure, you can *say* that. But how do you draw it on a diagram

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 08:22 PM, Mark Lawrence wrote: > You appear to have the same level of knowledge of Python internals as > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have > some fun, is Python pass by value or pass by reference? It has to be > more interesting debating that

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 10:23:24 PM UTC-4, Mark Lawrence wrote: > On 13/09/2015 01:44, rurpy--- via Python-list wrote: > > On 09/12/2015 06:02 PM, Ned Batchelder wrote: > >> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: > >> [...] > >> But in C, pointers mean

Re: Terminology: "reference" versus "pointer"

On 09/12/2015 05:39 PM, Rustom Mody wrote: > On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@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

Re: Terminology: "reference" versus "pointer"

On 13/09/2015 01:44, rurpy--- via Python-list wrote: On 09/12/2015 06:02 PM, Ned Batchelder wrote: On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote: [...] But in C, pointers mean more than that. You can perform arithmetic on them, to access memory as a linearly

Re: Terminology: “reference” versus “pointer”

Mark Lawrence writes: > No it isn't. When you make a copy of an object you will end up with > two names that refer to the same object. No, when you *make a copy of* an object, you get two objects. >>> x = [1, 2, 3] >>> y = copy.copy(x) >>> x is y False What you make

Re: Terminology: “reference” versus “pointer”

On Sat, Sep 12, 2015 at 4:26 PM, Ben Finney wrote: > If you do agree with those, some corollaries follow: > > * Container types do not contain objects. > > It is a useful analogy to say the objects are “in” the container; but > that would imply they are not

Re: Terminology: “reference” versus “pointer”

On Sat, Sep 12, 2015 at 3:03 PM, Random832 wrote: >> You can't, for example, keep the old reference (there are no references >> to references in Python), because they're not accessible as values in >> themselves. Once you assign a different reference, the old one is gone

Re: Terminology: “reference” versus “pointer”

On 12/09/2015 06:42, Random832 wrote: Ben Finney writes: The reference value is inaccessible to the program, it can only be used to get at the referenced object. That's like saying an integer is inaccessible since it can only be used to add/subtract/etc (list of

Re: Terminology: “reference” versus “pointer”

Random832 writes: > Ben Finney writes: > > The reference value is inaccessible to the program, it can only be > > used to get at the referenced object. > > What does it mean to access something, if not to do some operation on > it? Getting the

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >How about lay-English ontology in which "point to" and "refer to" are fairly > >synonymous? > > This I have found is important in teaching,

Re: Terminology: "reference" versus "pointer"

In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: >How about lay-English ontology in which "point to" and "refer to" are fairly >synonymous? This I have found is important in teaching, which is why I favour 'bind' and 'binding' -- rather than pointer, pointer, refer to,

Re: Terminology: "reference" versus "pointer"

On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > Random832 writes: > > > Ben Finney writes: > > > The reference value is inaccessible to the program, it can only be > > > used to get at the referenced object. > > > > What does it mean to access something, if not to do

Re: Terminology: “reference” versus “pointer”

Ben Finney writes: > With the significant difference that “pointer” implies that it has its > own value accessible directly by the running program, such as a pointer > in C. Its own value *is* what you're accessing when you assign or return it. You just can't do math

Re: Terminology: “reference” versus “pointer”

Random832 writes: > Ben Finney writes: > > With the significant difference that “pointer” implies that it has its > > own value accessible directly by the running program, such as a pointer > > in C. > > Its own value *is* what you're

Re: Terminology: “reference” versus “pointer”

Ben Finney writes: > Random832 writes: > >> Ben Finney writes: >> > With the significant difference that “pointer” implies that it has its >> > own value accessible directly by the running program, such as a

Re: Terminology: “reference” versus “pointer”

Random832 writes: > Ben Finney writes: > > > Random832 writes: > > > >> Ben Finney writes: > >> > With the significant difference that “pointer” implies that it has its > >> > own value

Re: Terminology: “reference” versus “pointer”

Ben Finney writes: > The reference value is inaccessible to the program, it can only be used > to get at the referenced object. That's like saying an integer is inaccessible since it can only be used to add/subtract/etc (list of all operations you can do with an

Terminology: “reference” versus “pointer” (was: Python handles globals badly.)

Random832 writes: > Honestly, whether you want to call the thing a pointer or a reference, > you have to call it *something*, and I think "reference" is a worse > fit based on its connotations from C++. Whatever you call it, it's an > arrow on a diagram. With the