Modifying Class Object
in [Python]
|
From: Steve Howell on 14 Feb 2010 03:15 On Feb 10, 6:16 am, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > > Alf, although your English in this forum has been excellent so far, I > understand you are Norwegian, so it is possible that you aren't a native > English speaker and possibly unaware that quotation marks are sometimes > ambiguous in English. > > While it is true that quoted text is officially meant to indicate a > direct quote, it is also commonly used in informal text to indicate a > paraphrase. (There are other uses as well, but they don't concern us now.) > > Unfortunately, this means that in informal discussions like this it is > sometimes difficult to distinguish a direct quote from a paraphrase, > except by context. In context, as a native speaker, I can assure you that > Stephen Hansen's use of quotation marks is a paraphrase and not meant to > be read as a direct quote. As another native speaker of English, I can assure Alf that using quotation marks in a paraphrase in written English is actually strictly admonished against in some English speaking countries. At least according to my English teachers. To the extent that many people on the Internet don't speak English natively, I think the most conservative and reasonable convention applies--use quotes to quote directly; if you're not quoting directly, omit quotes and make clear the fact that you are paraphrasing. Which isn't to say we don't all make mistakes. I have no idea about what Stephen Hanson said. Most misattributions are actually paraphrases, whether they be in quotes or not.
From: Steven D'Aprano on 14 Feb 2010 10:11 On Sat, 13 Feb 2010 23:45:47 -0800, Steve Howell wrote: > The term "pointer" is very abstract. Please give me a concrete > definition of a pointer. A programming language data type whose value directly specifies (or "points to") another value which is stored elsewhere in the computer memory. I quote from Wikipedia: http://en.wikipedia.org/wiki/Pointer_(computing) [quote] A pointer is a simple, less abstracted implementation of the more abstracted reference data type [end quote] And later: [quote] While "pointer" has been used to refer to references in general, it more properly applies to data structures whose interface explicitly allows the pointer to be manipulated (arithmetically via pointer arithmetic) as a memory address... [end quote] And again: [quote] A memory pointer (or just pointer) is a primitive, the value of which is intended to be used as a memory address; it is said that a pointer points to a memory address. It is also said that a pointer points to a datum [in memory] when the pointer's value is the datum's memory address. More generally, a pointer is a kind of reference, and it is said that a pointer references a datum stored somewhere in memory; to obtain that datum is to dereference the pointer. The feature that separates pointers from other kinds of reference is that a pointer's value is meant to be interpreted as a memory address, which is a rather 'low-level' concept. [end quote] > A curly brace is one of these: { } > > Pretty concrete, I hope. But { and } are glyphs in some typeface. Chances are that what you see, and what I see, are quite different, and whatever pixels we see, the compiler sees something radically different: two abstract characters implemented in some concrete fashion, but that concrete fashion is a mere implementation detail. They could be implemented as bytes x7b and x7d, or as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows what in some other system. So the *concrete* representation of the curly brace varies according to the system. From that, it's not a difficult leap to say that Pascal's BEGIN and END key words are mere alternate spellings of the abstract "open curly brace" and "close curly brace" with different concrete representations, and from that it's a small step to say that the INDENT and DEDENT tokens seen by the Python compiler (but absent from Python source code!) are too. >> But reference also has a concrete meaning: C++ has a type explicitly >> called "reference": >> >> http://en.wikipedia.org/wiki/Reference_(C++) >> >> > Of course, "reference" has concrete meanings in specific contexts. But I > can refer you to much more general and abstract uses of the term > "reference." Do you want references? I will be happy to refer you to > appropriate references. I know that reference can also be used in the abstract. I'm just warning that it can also be used in the concrete, and so we need to be wary of misunderstandings and confusions. >> And of course call-by-reference (or pass-by-reference) has a specific, >> technical meaning. >> >> > Which is what? http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference -- Steven
From: Steve Howell on 14 Feb 2010 12:51 On Feb 14, 7:11 am, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > On Sat, 13 Feb 2010 23:45:47 -0800, Steve Howell wrote: > > The term "pointer" is very abstract. Please give me a concrete > > definition of a pointer. > > A programming language data type whose value directly specifies (or > "points to") another value which is stored elsewhere in the computer > memory. > > I quote from Wikipedia: > > http://en.wikipedia.org/wiki/Pointer_(computing) > > [quote] > A pointer is a simple, less abstracted implementation of the > more abstracted reference data type > [end quote] > > And later: > > [quote] > While "pointer" has been used to refer to references in > general, it more properly applies to data structures whose > interface explicitly allows the pointer to be manipulated > (arithmetically via pointer arithmetic) as a memory > address... > [end quote] > > And again: > > [quote] > A memory pointer (or just pointer) is a primitive, the value > of which is intended to be used as a memory address; it is said > that a pointer points to a memory address. It is also said that > a pointer points to a datum [in memory] when the pointer's value > is the datum's memory address. > > More generally, a pointer is a kind of reference, and it is said > that a pointer references a datum stored somewhere in memory; to > obtain that datum is to dereference the pointer. The feature that > separates pointers from other kinds of reference is that a > pointer's value is meant to be interpreted as a memory address, > which is a rather 'low-level' concept. > [end quote] > > > A curly brace is one of these: { } > > > Pretty concrete, I hope. > > But { and } are glyphs in some typeface. Chances are that what you see, > and what I see, are quite different, and whatever pixels we see, the > compiler sees something radically different: two abstract characters > implemented in some concrete fashion, but that concrete fashion is a mere > implementation detail. They could be implemented as bytes x7b and x7d, or > as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows > what in some other system. So the *concrete* representation of the curly > brace varies according to the system. > > From that, it's not a difficult leap to say that Pascal's BEGIN and END > key words are mere alternate spellings of the abstract "open curly brace" > and "close curly brace" with different concrete representations, and from > that it's a small step to say that the INDENT and DEDENT tokens seen by > the Python compiler (but absent from Python source code!) are too. > Thanks. It's a useful analogy; I think I understand your point better. I've been bouncing around between Python and Javascript a lot lately, so your analogy resonates with me. There are many times when I find myself simply respelling things like begin/end, and those respellings to me almost make me think of Python and Javascript as different dialects of an underlying language. Of course, there are other places where the languages differ more substantively, too. Going back to pointers vs. references, I think the key distinction being made is that pointers allow specific memory manipulation, although I think even there you're really just dealing with abstractions. The address 0x78F394D2 is a little bit closer to the machine than, say, the 42nd element of a Python list, but they are both just abstractions on top of underlying machines, whether the machines are virtual, electronic circuits, vacuum tubes, whatever. You can add 6 to 42 and get the 48th object, but its Python's convention not to call the 48th object a memory address or expose a reference to it as a pointer. If I want to pass along the reference to the 48th element of a list as the slot to be updated (i.e. with the intention to actually mutate the list itself), then I need a tuple like (lst, 48).
From: Ethan Furman on 14 Feb 2010 18:41 Steve Howell wrote: > On Feb 14, 7:11 am, Steven D'Aprano <st...(a)REMOVE-THIS- > cybersource.com.au> wrote: > >>On Sat, 13 Feb 2010 23:45:47 -0800, Steve Howell wrote: >> >>>The term "pointer" is very abstract. Please give me a concrete >>>definition of a pointer. >> >>A programming language data type whose value directly specifies (or >>"points to") another value which is stored elsewhere in the computer >>memory. >> >>I quote from Wikipedia: >> >>http://en.wikipedia.org/wiki/Pointer_(computing) >> >> [quote] >> A pointer is a simple, less abstracted implementation of the >> more abstracted reference data type >> [end quote] >> >>And later: >> >> [quote] >> While "pointer" has been used to refer to references in >> general, it more properly applies to data structures whose >> interface explicitly allows the pointer to be manipulated >> (arithmetically via pointer arithmetic) as a memory >> address... >> [end quote] >> >>And again: >> >> [quote] >> A memory pointer (or just pointer) is a primitive, the value >> of which is intended to be used as a memory address; it is said >> that a pointer points to a memory address. It is also said that >> a pointer points to a datum [in memory] when the pointer's value >> is the datum's memory address. >> >> More generally, a pointer is a kind of reference, and it is said >> that a pointer references a datum stored somewhere in memory; to >> obtain that datum is to dereference the pointer. The feature that >> separates pointers from other kinds of reference is that a >> pointer's value is meant to be interpreted as a memory address, >> which is a rather 'low-level' concept. >> [end quote] >> >> >>>A curly brace is one of these: { } >> >>>Pretty concrete, I hope. >> >>But { and } are glyphs in some typeface. Chances are that what you see, >>and what I see, are quite different, and whatever pixels we see, the >>compiler sees something radically different: two abstract characters >>implemented in some concrete fashion, but that concrete fashion is a mere >>implementation detail. They could be implemented as bytes x7b and x7d, or >>as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows >>what in some other system. So the *concrete* representation of the curly >>brace varies according to the system. >> >>From that, it's not a difficult leap to say that Pascal's BEGIN and END >>key words are mere alternate spellings of the abstract "open curly brace" >>and "close curly brace" with different concrete representations, and from >>that it's a small step to say that the INDENT and DEDENT tokens seen by >>the Python compiler (but absent from Python source code!) are too. >> > > > Thanks. It's a useful analogy; I think I understand your point > better. I've been bouncing around between Python and Javascript a lot > lately, so your analogy resonates with me. There are many times when > I find myself simply respelling things like begin/end, and those > respellings to me almost make me think of Python and Javascript as > different dialects of an underlying language. Of course, there are > other places where the languages differ more substantively, too. > > Going back to pointers vs. references, I think the key distinction > being made is that pointers allow specific memory manipulation, > although I think even there you're really just dealing with > abstractions. The address 0x78F394D2 is a little bit closer to the > machine than, say, the 42nd element of a Python list, but they are > both just abstractions on top of underlying machines, whether the > machines are virtual, electronic circuits, vacuum tubes, whatever. > You can add 6 to 42 and get the 48th object, but its Python's > convention not to call the 48th object a memory address or expose a > reference to it as a pointer. If I want to pass along the reference > to the 48th element of a list as the slot to be updated (i.e. with the > intention to actually mutate the list itself), then I need a tuple > like (lst, 48). > I think that's the key right there -- if 48 was really a pointer, you wouldn't need to pass lst in as 48 would in fact be the memory address of the object you wanted to manipulate. ~Ethan~
From: Alf P. Steinbach on 14 Feb 2010 19:41
* Ethan Furman: > Steve Howell wrote: >> >> Going back to pointers vs. references, I think the key distinction >> being made is that pointers allow specific memory manipulation, >> although I think even there you're really just dealing with >> abstractions. The address 0x78F394D2 is a little bit closer to the >> machine than, say, the 42nd element of a Python list, but they are >> both just abstractions on top of underlying machines, whether the >> machines are virtual, electronic circuits, vacuum tubes, whatever. >> You can add 6 to 42 and get the 48th object, but its Python's >> convention not to call the 48th object a memory address or expose a >> reference to it as a pointer. If I want to pass along the reference >> to the 48th element of a list as the slot to be updated (i.e. with the >> intention to actually mutate the list itself), then I need a tuple >> like (lst, 48). >> > > I think that's the key right there -- if 48 was really a pointer, you > wouldn't need to pass lst in as 48 would in fact be the memory address > of the object you wanted to manipulate. The generalization is known as a "based pointer". Except where it's a fundamental abstraction in a programming language, where it might be called anything. For example, in C++ some so called "member pointers" are logically based pointers. They have pointer syntax (as do C++ iterators, which are not necessarily pointers), but member pointers are not pointers in the C++ standard's sense; in particular, dereferencing a C++ member pointer yields a typeless entity, which is not the case for a normal pointer, although that standard confusingly calls also member pointers pointers in some places, and in other places uses the pointer term only about basic pointers. So, delving into the details of that terminology means traveling into a pretty chaotic territory. But on the other hand, going for the more abstract it gets cleaner and simpler. The Wikipedia article is about in the middle somewhere. It is perhaps not confusing that it is confusing to many. :-) Cheers & hth., - Alf |