Re: Modifying Class Object
Hi Groetjes Albert, I spotted your comment - re: pointers http://groups.google.com/group/comp.lang.python/msg/5c1e25919b6a74bf On Feb 22, 11:44 pm, Albert van der Horst alb...@spenarnc.xs4all.nl wrote: (I once studied algol 68, and never got confused about these subjects anymore, recommended.) Having used Algol68, then switching to C to discover * for manual dereferencing I immediately wanted to be back using A68 again, but alas... Then when I switched to C++ I immediately understood the Zen of C++'s ... but still wanted to switch back to A68. Was there ever a version with Objects... I saw a version with Areas but have no idea what an Area is. @Albert: Given the domain name xs4all in your email address I am sure YOU have spotted: http://www.xs4all.nl/~jmvdveer/algol.html by Marcel Also: I invite you to join one of the below groups (my .sig below) and deposit some of your Algol68 impressions There is also a chrestomathy site http://rosettacode.org/wiki/ALGOL_68 where you can pick out an code sample unimplemented in Algol68 and torture test your Algol68 memories. (Be warned: Most of the easy samples are done) Keep in touch NevilleDNZ -- For Algol68-user mailinglist with archives subscription: * https://lists.sourceforge.net/lists/listinfo/algol68-user To download Linux's Algol68 Compiler, Interpreter Runtime: * http://sourceforge.net/projects/algol68 Join the linkedin.com's Algol68 group, follow: * http://www.linkedin.com/groups?gid=2333923 -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
In article mailman.2343.1265860271.28905.python-l...@python.org, Steve Holden st...@holdenweb.com wrote: Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: [snip] Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. [snip] If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. You go too far here. What you are referring to in your bizarrely constructed definition above No, it's not bizarre, it's the standard general language independent definition. *The* standard general language independent definition? As defined where? The id() value doesn't correspond to the pointer value, it corresponds to the object. Why you see the need for this indirection remains a mystery. No it doesn't. If an object is garbage collected, the id() might be recycled. At that time the id() corresponds to quite a different object. OTOH if you kill an object in Python it is gone forever. Of course there is a standard computer science idea of what a pointer is. If you admit the pointer terminology, you can understand that a pointer value is all what id() can tell us. You seem to subsconsciously substitute assembler language address for it. When someone says: pointers are bad what really meant is manipulating assembler language addresses in a high level language is bad. (Everybody agrees, but sometimes you must use e.g. c as sort of assembler.) That is not the kind of pointers we're talking about here. (I once studied algol 68, and never got confused about these subjects anymore, recommended.) regards Steve -- Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. alb...@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf said (2/13/2010 8:34 PM): Names in Python refer to objects. Those references can be copied via assignment. That's (almost) all. And it provides a very short and neat way to describe pass by sharing. Alf also said (2/13/2010 8:43 PM): * Steve Howell: This thread is interesting on many levels. What is the core question that is being examined here? I think that regarding the technical it is whether a Python name refers to an object or not. I maintain that it does, and that the reference can be copied, and that the semantics of the language requires this and is defined in terms of this. Steve Holden, D'Aprano and many others maintain that there are no references, or that if there are then they're only an implementation aspect, i.e. that conceiveable one could have an implementation without them. Steve D'Aprano said (2/14/2010 12:13 AM): That's not to say that the general concept of references (as in to refer to) isn't valuable when discussing Python. If you want to say that (e.g.) following x = 1 the name x refers to (or even points to!) the object 1, my objections will be mild or non-existent. In that sense, it's probably impossible to program without some sort of references: the computer manipulates variables or objects directly, while we manipulate characters in source code. The only way to write a program is to use some abstract thing (a name, an offset, whatever) that refers, in some fashion, to a collection of bits in the computer's memory. But to go from that to the idea that (say) x is a pointer does so much violence to the concept of pointer and has so much room for confusion that it is actively harmful. I think most of the technical argument in this thread comes down to the various forms of the word *refer*. After execution of this Python statement: x = 5 ... we can use this English-language statement: the name *x* refers to the value *5* (If anyone has more than Steve's mild objection, please speak up!) The English-language statement uses the VERB refers. It is not the same as using the NOUN reference: *x* is a reference to the value *5* Why not? Because using the NOUN form suggests that you're talking about a particular kind of object in the world Python, as in these statements: *x* is a string *x* is a function *x* is a class But Python does not define *reference* objects -- by which I mean that executing *import types; dir(types)* produces a long list of object-type names, and there's nothing like a reference on that list. (I suspect there's a better way to make this there are no reference objects argument. Can anyone help?) Amending the statement to: the name *x* is a reference to the value *5* ... doesn't really help matters. Is *x* a NAME or is it a REFERENCE? Looking again at Alf's assertion: [the core technical question is] whether a Python name refers to an object or not. I maintain that it does, and that the reference can be copied, ... and Alf's example (message dated 2/10/2010 5:02 PM): For example, x = s[0] accesses the object that s points (refers) to. I believe Alf would characterize this assignment statement as a situation in which a reference is copied [using the NOUN form of refer]. But no object is copied during execution of this statement. Moreover, saying a reference is copied might mislead a Python newbie into thinking that some kind of reference object exists that can be copied by Python statements. So it's better to describe the situation using the VERB form of refer: assigns the name *x* to the object that *s[0]* refers to -John -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
John Posner jjpos...@optimum.net writes: [...] x = s[0] [...] assigns the name *x* to the object that *s[0]* refers to s[0] does not refer to an object, it *is* an object (once evaluated of course, otherwise it's just a Python expression). -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Mon, 15 Feb 2010 21:25:23 +, Arnaud Delobelle wrote: John Posner jjpos...@optimum.net writes: [...] x = s[0] [...] assigns the name *x* to the object that *s[0]* refers to s[0] does not refer to an object, it *is* an object (once evaluated of course, otherwise it's just a Python expression). Precisely. Treated as an expression, that is, as a string being evaluated by the compiler, we would say that it *refers to* an object (unless evaluation fails, in which case it refers to nothing at all). But treated as whatever you get after the compiler is done with it, that is, post- evaluation, we would say that it *is* an object. This subtle distinction is essentially the difference between a label and the thing that is labeled. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Mon, 15 Feb 2010 21:25:23 +, Arnaud Delobelle wrote: John Posner jjpos...@optimum.net writes: [...] x = s[0] [...] assigns the name *x* to the object that *s[0]* refers to s[0] does not refer to an object, it *is* an object (once evaluated of course, otherwise it's just a Python expression). Precisely. Treated as an expression, that is, as a string being evaluated by the compiler, we would say that it *refers to* an object (unless evaluation fails, in which case it refers to nothing at all). But treated as whatever you get after the compiler is done with it, that is, post- evaluation, we would say that it *is* an object. This subtle distinction is essentially the difference between a label and the thing that is labeled. The main differences between a pure functional language where that view can hold and be reasonable, and a language like Python, are that * Python assignments change which object a name refers to, /at runtime/. - Name binding is run time action, not a compile time action. Without run time binding names couldn't be reassigned. s = 1; s = 2 * Some Python objects are modifiable (a.k.a. mutable). - This is particularly important when two or more names refer to the same object and that object is modified. That is, a simple-minded transfer of concepts from pure functional programming to Python breaks down in these cases[1]. I hope this explanation of exactly where the functional programming enthusiasts here go wrong can be of help to readers of the thread, although I've given up hope on those holding the functional programming view (since I'm only human, and even the Gods contend in vain against that sort of thing). Cheers hth., - Alf Notes: [1] Steven D'Aprano's focus on compilation rather than execution mainly ignores the first point, that a name in given a statement in a loop, say, can refer to different objects in different loop iterations. Happily the Python language specification explains binding as a run-time action. Binding is not a compile time action in Python, it is a run-time action, and can bind a given name in a given statement within the same routine execution, to different objects, and the language specification of course uses the phrase refers to to explain the situation after a run time binding. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On 2/15/2010 6:09 PM, Steven D'Aprano wrote: On Mon, 15 Feb 2010 21:25:23 +, Arnaud Delobelle wrote: John Posnerjjpos...@optimum.net writes: [...] x = s[0] [...] assigns the name *x* to the object that *s[0]* refers to s[0] does not refer to an object, it *is* an object (once evaluated of course, otherwise it's just a Python expression). Precisely. Treated as an expression, that is, as a string being evaluated by the compiler, we would say that it *refers to* an object (unless evaluation fails, in which case it refers to nothing at all). But treated as whatever you get after the compiler is done with it, that is, post- evaluation, we would say that it *is* an object. This subtle distinction is essentially the difference between a label and the thing that is labeled. Is this your only quibble with my writeup? If, so, I'm gratified. And your objections make perfect sense. Still, I'll attempt to justify my phrasing. I was originally going to write: assigns the name *x* to the object that THE NAME *s[0]* refers to ... but I didn't want to start a distracting argument on the use of the phrase *the name* to describe the 4-char string *s[0]*. So now I'll try to (briefly) make my case. Yes, it might be more correct to say that *s[0]* is an expression (equivalent to the more obvious expression *s.__getitem__(0)*). But in common usage, the 4-char string *s[0]* _behaves_ like a name. If you accept this viewpoint, the story on Python assignment statements becomes quite simple ... Syntactic sugar aside, there are only two kinds of assignment statements: 1. NAME = EXPRESSION The EXPRESSION creates a new object, and the NAME is assigned to that object. Examples: x = x + 1 obj = MyClass(1, 2, red) mywordlist = mysentence.split() 2. NAME2 = NAME1 No new object is created. NAME2 becomes another name (an alias) for the existing object that currently has NAME1 assigned to it. Examples: y = x s[0] = s[42] mydict[spamwich] == this_sandwich obj.color = MYCOLORS.LTGREEN This viewpoint might fail in advanced areas of Python programming: properties/descriptors, double-underscore methods, etc. But in my own day-to-day usage (admittedly, I'm a hobbyist Python programmer, not a professional), it's never failed me to think this way: * A dict is a collection of user-devised names, each of which is assigned to an object. * A list/tuple is an interpreter-maintained collection of integer names (0, 1, 2, ...), each of which is assigned to an object. * A class instance is very much like a dict. Tx, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 10, 6:16 am, Steven D'Aprano st...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sat, Feb 13, 2010 at 7:59 AM, Michael Sparks spark...@gmail.com wrote: Hi Alf, On Feb 12, 8:22 pm, Alf P. Steinbach al...@start.no wrote: Thanks for the effort at non-flaming discussion, it *is* appreciated. I would appreciate it if you tried to be non-flaming yourself, since you can see I am not flaming you. I'm currently in a self-imposed exile from commenting on any particular details of the technical issue in this thread as I believe it futile, but I have to say: wow, kudos to you for putting SO much into saying what I tried to say, and doing so better then I was able to. Kudos. Times two. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sun, Feb 14, 2010 at 12:15 AM, Steve Howell showel...@yahoo.com wrote: On Feb 10, 6:16 am, Steven D'Aprano st...@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. Well, no, I have to stand in my defense at this point. Given the context of the communication medium, an actual quote has IMHO a clearly defined context. It is lines, unchanged and unedited, prepended with a certain appropriate set of characters, and clearly cited with some variation of something like On date, Someone said: A quote, in context, is an attempt to directly reference another individual's words as they spoke them. Any alteration of such words, any adjustment of such words to your own end, is dishonest. What I did was say something like this paragraph (with no quote characters before it): And then you hand-waved my arguments with a response of, this that blah bleh Minus the indention. There was IMHO, NO misattribution, NO reasonable assumption that I specified actual or explicit words of Alf or anyone else. There MAY be an argument someone can make claiming my statement wasn't clear, but to declare it is a deliberate /lie/ is another thing entirely. There is a difference between using quote marks and making an actual quotation-- a quotation requires a citation-- and in informal discourse use of quote marks to represent clear paraphrasing of the interpretation of position is valid, imho. In a formal paper or thesis, I'd use a different format. But this is not formal. In context that statement can not possibly be reasonable considered an actual quotation, even with quote marks. And I'm responding because: yes, I'm finding this You are a liar. response particularly personally offensive. I should get over it. I'm just used to people disagreeing with me. Dismissing me as a liar is something new. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
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 x007b and x007d 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 14, 7:11 am, Steven D'Aprano st...@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 x007b and x007d 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).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Steve Howell wrote:
On Feb 14, 7:11 am, Steven D'Aprano st...@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 x007b and x007d 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~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Fri, Feb 12, 2010 at 6:23 PM, rantingrick rantingr...@gmail.com wrote: [blah, blah, blah] First of all, we all know how D Aprano has such an unfettered ego problem. [blah, blah, blah] And as always the roaches start coming out of the woodwork in a most pathetic puppy dog way. What would you puppets do if there were no one to pull your strings? [blah, blah, blah] (I'd claim an ad hominem attack, but that's just boring these days) But the most nortoriuos behavior of all belongs to none other that the PSF chairman himself! Yes Steve Holden, you should be ashamed of yourself! [blah, BLAH, blah] Your attacks have been more amd more destructive over the past year or so. Even if your behavoir could somehow be justified how can someone in your position lead the PSF and act as such an infintile way? [blah, blah, BLAH, blah] I am very ashamed of you Steve and you really owe Alf (and the community at large) an apology although i doubt it will happen because then your own people will turn against you. Blah. Blah. Blah. Grow up. I've deliberately exited the real topic of this thread, because its clearly degenerated to complete nonsense; while in this thread Alf argues for a certain dogmatic theoretical Standard terminology that clearly many people disagree with (supporting the 'standard' continually with a certain language's reference manual, which by definition makes it not-standard, or you wouldn't need to quote a certain language0, and in another he argues for another position-- and and speaks in support of standard and understood terminology, the two positions together are laughable nonsense. To this he will, of course, again declare that I am simply lying. This very declaration clearly proves his own absurdity: you can argue in a circle for infinity, but when you start spouting nonsense about how those opposing you are mere liars-- ESPECIALLY-- when you have been arguing about how you have been the terrible victim of ad hominem attacks-- your own hypocrisy makes your words meaningless. I've been tempted to re-enter the actual argument, its a hard one to avoid with such clear misunderstandings held so strongly. But, I won't. Except for my editorials here. Because I am weak. Ahem, the point is-- my chief antagonist in the discussion has publicly stated I am a liar. This is provably a lie unto itself, and it damns the speaker absolutely. I have expressed my position, my thoughts, and my opinion and interpretation of my opponents position -- and his response is, You are a liar. or, That is a lie. That's a lie, a personal attack, all the while declaring his own victimhood. You can say, You're mistaken, but to say, You are a liar. is something else entirely. The chief victim of c.p.l. becomes the abuser. Now, why am I entering this thread again? Not to discuss the issue at hand. There's clearly no point. Alf has chosen to define language in his own way, ignoring any weight that established industry weight might apply to such terms. Okay. When you enter an argument of words, some people will refuse to acknowledge their own perception of the world isn't reality. It happens. There's no point in going forward after a certain point. But now, this absurdity? You are ashamed of Steve Holden for his behavior? You think he owes the community at large an apology? I don't mean to rise up in defense of Holden, as I'm sure he can defend himself should he feel the need. I took offense at Alf choosing to claim the right of defending me earlier, so I can't be a hypocrite in that. But, really. If -this- is your position? Grow up. Seriously. Steve Holden owes this community nothing. That which he has given should be welcomed and he should be thanked for it. He hasn't flamed anyone; he hasn't attacked anyone-- despite Alf's nonsense claims, though on occasion his responses are snarky (with reason)-- he hasn't /taken/ anything from this community. He's done far more then many in assisting people who are trying to learn Python and embrace its community. Frankly, how dare you claim to demand an apology for this community. If I was to be ashamed of anyone's participation in the community, it would be you over him. I'm not even ashamed of Alf. I don't agree with him, I think he's got a stubborn egocentric view of terminology and semantics which is ultimately harmful, I think he has a severe persecution complex, but despite this-- I've seen him respond to several threads recently, helpfully, and I don't even disagree with most of those responses. You're just ... blabbering. Adding arbitrary, unsupported, and unsupportable fuel to the fire to rant at some position-- how /mean/ this community is and how /terrible/ we behave-- all without any basis at all. Except you claim it. You document it. Gee, we're mean, mean, unhelpful people. And no, I'm not one of his people who will turn on him for admitting he is satan; if Steve Holden and I have ever been in a thread in the past -- it was us both
Re: Modifying Class Object
In article mailman.2323.1265836683.28905.python-l...@python.org, Steve Holden st...@holdenweb.com wrote: Whether in CPython, Jython or IronPython the value returned by calling id(x) (whether x is a literal, a simple name or a more complex expression) is absolutely no use as an accessor: it does not give you access to the referenced value. If you disagree, please write (in any implementation you like: it need not even be portable, though I can't imagine why ti wouldn't be) a Python function which takes an id() value as its argument and returns the value for which the id() value was provided. IIRC, I've seen ctypes code that uses id() to get access to the object, but (obviously) I don't think that invalidates your point[er]. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
In article mailman.2489.1266053149.28905.python-l...@python.org,
Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Fri, 12 Feb 2010 18:23:46 -0800 (PST), rantingrick
rantingr...@gmail.com declaimed the following in
gmane.comp.python.general:
This entire thread has imploded like a neutron star into an infantile
debate that only Caddie Couric, Bill O Reilly, and everyone on PMS-NBC
can hold a candle to! The only post i enjoyed was Steve Howes!
{Hmm, I don't recall ever seeing a rantingrick on the group before...
could it be... a... sockpuppet?}
Zie's been around a while.
--
Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/
At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Hi Alf,
On Feb 12, 8:22 pm, Alf P. Steinbach al...@start.no wrote:
Thanks for the effort at non-flaming discussion, it *is*
appreciated.
I would appreciate it if you tried to be non-flaming yourself,
since you can see I am not flaming you.
I was seeking to educate you on a simple matter which you seem
to be misunderstanding in python. This will be my second and
last attempt to do so since you chose to be inflammatory in your
response. (In case you do not understand what I find inflammatory,
I will discuss that at the end)
Please note below I may use CAPS occasionally. Whilst usually
taken as shouting, I mean them as BOLD. Please be aware of this :-)
My reason for choosing to do reply is for the simple reason
that recently I had similar discussions with a colleague who was
likewise stuck talking about implementation aspects (call by
reference/value rather than call with object/sharing).
Before I start, note we're talking about semantics, not
implementation. That distinction is very important.
Yes.
[ inflammatory comment snipped]
Good - common ground - a good starting point.
Now, if I define a language, this has 3 main parts:
* Syntax
* Semantics
* Implementation
The syntax of python is simply and shortly defined in a machine
readable format, and is therefore not interesting to discuss
here.
The implementation of python is similarly well defined. There are
multiple such implementations, one of which is CPython.
However, all those references to implementation aspects,
persisting
[ inflammatory comment snipped]
In theory when talking about a language, we do not need to talk
about implementation details. However when using a language,
implementation details do matter as well.
That's why people talk about implementation aspects. When talking
about how the language is defined, you need to talk about how the
language is defined. It's not defined in terms of Java pointers or
references. It's defined in terms of objects and names. (Or objects
and labels)
The exception to this is with pure functional language. In a pure
functional language I do not care about implementation details,
since they are outside the scope of the language.
It is worth noting that python and functional languages share a
common ethos - though with different conclusions - that optimising
for the programmers expression of the problem rather than for the
machine *matters*.
If you miss this, you will be stuck misunderstanding python,
pretty much forever. If you (the reader, not necessarily Alf)
understand this, good. If you don't, you need to re-read this
and really understand it.
(please bear in mind when I say YOU in that paragraph, I
mean whomever is reading this, not anyone specific)
Let's get down to brass tacks.
In python, the LANGUAGE, there are no pointers or references,
much like in SML, haskell and friends there are no pointers or
references. I'm using SML here as an example, because it is
conceptually close to python in terms to some aspects of
evaluation and how it deals with names and values. (There
are many differences as well, but we're dealing with calling,
names values, in which they are close enough)
Taking an example from SML:
structure Stk =
struct
exception EmptyStack;
datatype 'x stack = EmptyStack | push of ('x * 'x stack);
fun pop(push(x,y)) = y | pop EmptyStack = raise EmptyStack;
fun top(push(x,y)) = x | top EmptyStack = raise EmptyStack;
end;
This may be used, say from the interactive prompt, as follows:
val x = EmptyStack; (* 1 *)
val 'x = x; (* 2 *)
val y = push(5,'x); (* 3 *)
val z = push(4,y); (* 4 *)
top z; (* 5 *)
Now, in this example, in SML, there are only names and values.
Unlike python, all values are immutable, and theoretically, no
sequencing of statements.
Now line 1 takes the EmptyStack value, and the name x is bound
to it. Line 2 takes that same EmptyStack value, and the name 'x
is also bound to it.
There are no pointers in SML, just names and values.
Like python, SML has aliases. 'x for example is an alias for x.
However that is just a symbolic name for the object itself.
When line 3 is evaluated, the value push(5, 'x) is bound to the
name y. Note - push(5, 'x) is in itself a value in SML, because
it has been defined as such in the Datatype definition in the
structure definition Stk.
When we reach line 5, the function top is called with the value
that z is bound to. Not a reference. Not a pointer. The actual
value. In this case z's value is push(4,push(5,EmptyStack)).
Thus the SML runtime evaluates the expression
top push(4,push(5,EmptyStack))
And returns the value 4.
In python, I don't have such richness of ability to define values,
but I have these types play with:
* numbers - 1.0 , 1, 1+2i, 0x11 0777
* strings - hello world
* lists - [hello, world ]
* tuples - (hello, world)
* dicts - {hello : world }
All of these types are defined in python as python objects. How
they are
Re: Modifying Class Object
* Aahz:
In article mailman.2323.1265836683.28905.python-l...@python.org,
Steve Holden st...@holdenweb.com wrote:
Whether in CPython, Jython or IronPython the value returned by calling
id(x) (whether x is a literal, a simple name or a more complex
expression) is absolutely no use as an accessor: it does not give you
access to the referenced value.
If you disagree, please write (in any implementation you like: it need
not even be portable, though I can't imagine why ti wouldn't be) a
Python function which takes an id() value as its argument and returns
the value for which the id() value was provided.
IIRC, I've seen ctypes code that uses id() to get access to the object,
Dino Viehland gave this code:
quote author=Dino Viehland
Just for fun this works in IronPython 2.6:
import clr
clr.AddReference('Microsoft.Dynamic')
from Microsoft.Scripting.Runtime import IdDispenser
x = object()
id(x)
43
IdDispenser.GetObject(43)
object object at 0x002B
IdDispenser.GetObject(43) is x
True
/quote
but (obviously) I don't think that invalidates your point[er].
For my part I didn't think the above would be possible without enumerating all
objects. I'm guessing that Steve didn't think so either. However, I seriously
doubt that an agreement with my earlier statements of that was his point,
considering the if above, which seems to imply to the reader that instead I'd
argued what he's challenging.
Perhaps Steve was just confused.
My original statement, with reference to the Java language spec, didn't say much
more about the language than that it has assignable references.
It took a long time to get the wild horses reined in in that direction.
But then two others ended up arguing that Python does not have references, with
one of them maintaining that refers to in the language spec does not mean
refers to, but instead means refers to, so I'm guessing it's religious, yes?
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!), I felt it necessary to respond. It turned out to be a long sequence of trivial fallacies, peppered with various allegations and insinuations.] [snip extremely much] Now let's move to the implementation aspects. Python as a language is implemented in many languages. One of these is C. There are compilers to C (pypy), C++ (shedskin), for the JVM (Jython) and .net (Ironpython). There is also an executable operation semantics for python, which can be found here: http://gideon.smdng.nl/2009/01/an-executable-operational-semantics-for-python/ This set of operational semantics is written in Haskell. Haskell is a strictly pure, lazily evaluated language. It therefore has no pointers or references, just values and names. The implementation therefore cannot be in terms of references and pointers. At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. There is need to talk about in reality (as if the language spec and general semantics isn't real enough) nor to talk about any specific implementation. [snip very much] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of rambling text. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. I see we are still all out of step with you. If it's a fallacy then I'd like to see a reasoned logical explanation of its fallaciousness. As far as I can see, if someone says implementing Python implies the use of pointers as you appear to be doing, then Michael's argument neatly demolishes that argument by providing a counter-example: there is an implementation of Python that does not use pointers. You, however, dismiss this as a fallacy, and suggests it somehow misrepresents you. And yet you wonder why people call your behavior (not you) paranoid. [...] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of rambling text. And you can say this without, by your own admission, even reading it. It makes me wonder why we have paid you the compliment of engaging you in debate, since this is the most transparent evidence to date that what comes back will be unrelated to the arguments presented. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sat, 13 Feb 2010 07:59:42 -0800, Michael Sparks wrote: Now, if I define a language, this has 3 main parts: * Syntax * Semantics * Implementation [snip] Michael, that is remarkable. Excellent work, thank you! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. I see we are still all out of step with you. Why did you snip the short argument? If it's a fallacy then I'd like to see a reasoned logical explanation of its fallaciousness. Oh, you snipped it so that you didn't have to present it to readers. That's dishonest, Steve Holden. Requoting: quote Now let's move to the implementation aspects. Python as a language is implemented in many languages. One of these is C. There are compilers to C (pypy), C++ (shedskin), for the JVM (Jython) and .net (Ironpython). There is also an executable operation semantics for python, which can be found here: http://gideon.smdng.nl/2009/01/an-executable-operational-semantics-for-python/ This set of operational semantics is written in Haskell. Haskell is a strictly pure, lazily evaluated language. It therefore has no pointers or references, just values and names. The implementation therefore cannot be in terms of references and pointers. At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote As far as I can see, if someone says implementing Python implies the use of pointers as you appear to be doing, then Michael's argument neatly demolishes that argument by providing a counter-example: there is an implementation of Python that does not use pointers. That's meaningless. But then so is maintaining that Python doesn't have references. And so is your argument applied to Pascal, just to mention that again. You, however, dismiss this as a fallacy, and suggests it somehow misrepresents you. And yet you wonder why people call your behavior (not you) paranoid. On top of the multiple fallacies, dubious snipping of arguments, statements that such arguments have not been presented (just after snipping them), and general misleading insinuations and misrepresentation, ad yet another bit of personal attack. Do you understand what that may say to readers about you, Steve Holden? Apparently it's all to defend an indefensible, idiotic position. But I think you're doing it at least partially for the fun of harassing someone. [...] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of rambling text. And you can say this without, by your own admission, even reading it. No, you can not quote any place I have said that I haven't read his article. I did read most of it. So you are yet again within the span of one posted article presenting untrue information that you know is not true. It makes me wonder why we have paid you the compliment of engaging you in debate, Gosh, I don't know. You must be stupid to do that. Yes? since this is the most transparent evidence to date that what comes back will be unrelated to the arguments presented. That is untrue, Steve Holden, and since you can't quote that evidence, since you evidently /have/ read my short article which you're responding to, knowing exactly what to snip, you know that what you're saying is untrue. I think this is your third lie in one posting. But who would care to count. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: * Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. I see we are still all out of step with you. Why did you snip the short argument? If it's a fallacy then I'd like to see a reasoned logical explanation of its fallaciousness. Oh, you snipped it so that you didn't have to present it to readers. That's dishonest, Steve Holden. Requoting: quote Now let's move to the implementation aspects. Python as a language is implemented in many languages. One of these is C. There are compilers to C (pypy), C++ (shedskin), for the JVM (Jython) and .net (Ironpython). There is also an executable operation semantics for python, which can be found here: http://gideon.smdng.nl/2009/01/an-executable-operational-semantics-for-python/ This set of operational semantics is written in Haskell. Haskell is a strictly pure, lazily evaluated language. It therefore has no pointers or references, just values and names. The implementation therefore cannot be in terms of references and pointers. At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote As far as I can see, if someone says implementing Python implies the use of pointers as you appear to be doing, then Michael's argument neatly demolishes that argument by providing a counter-example: there is an implementation of Python that does not use pointers. That's meaningless. But then so is maintaining that Python doesn't have references. And so is your argument applied to Pascal, just to mention that again. You, however, dismiss this as a fallacy, and suggests it somehow misrepresents you. And yet you wonder why people call your behavior (not you) paranoid. On top of the multiple fallacies, dubious snipping of arguments, statements that such arguments have not been presented (just after snipping them), and general misleading insinuations and misrepresentation, ad yet another bit of personal attack. Do you understand what that may say to readers about you, Steve Holden? Apparently it's all to defend an indefensible, idiotic position. But I think you're doing it at least partially for the fun of harassing someone. [...] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of rambling text. And you can say this without, by your own admission, even reading it. No, you can not quote any place I have said that I haven't read his article. I did read most of it. So you are yet again within the span of one posted article presenting untrue information that you know is not true. It makes me wonder why we have paid you the compliment of engaging you in debate, Gosh, I don't know. You must be stupid to do that. Yes? since this is the most transparent evidence to date that what comes back will be unrelated to the arguments presented. That is untrue, Steve Holden, and since you can't quote that evidence, since you evidently /have/ read my short article which you're responding to, knowing exactly what to snip, you know that what you're saying is untrue. I think this is your third lie in one posting. But who would care to count. Cheers hth., - Alf You really are the most insulting arrogant bastard I've ever read on
Re: Modifying Class Object
On Sat, Feb 13, 2010 at 7:50 PM, Alf P. Steinbach al...@start.no wrote: At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote You're actually just proving his point here. It doesn't matter what model Haskell uses, a version of Pascal implemented in Haskell has pointers. Likewise, regardless of what model the implementation of Python uses, Python itself doesn't have pointers, it has objects and names. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Benjamin Kaplan: On Sat, Feb 13, 2010 at 7:50 PM, Alf P. Steinbach al...@start.no wrote: At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote You're actually just proving his point here. It doesn't matter what model Haskell uses, a version of Pascal implemented in Haskell has pointers. Yes, that kills his argument. As you note, the Haskell bit is completely irrelevant. So his use of Haskell implementation as a no pointers argument is completely bogus, a fallacy. Likewise, regardless of what model the implementation of Python uses, Python itself doesn't have pointers, it has objects and names. Well that's wrong for at least one general meaning of pointer, but why quibble about terminology? Names in Python refer to objects. Those references can be copied via assignment. That's (almost) all. And it provides a very short and neat way to describe pass by sharing. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Howell: This thread is interesting on many levels. What is the core question that is being examined here? I think that regarding the technical it is whether a Python name refers to an object or not. I maintain that it does, and that the reference can be copied, and that the semantics of the language requires this and is defined in terms of this. Steve Holden, D'Aprano and many others maintain that there are no references, or that if there are then they're only an implementation aspect, i.e. that conceiveable one could have an implementation without them. Regarding some other issues it seems to be a childish exercise in flaming, a flame war, with claims of insanity, incompetence, lying (that's actually from me, I reacted a bit strongly to faked quoting + conclusions from that in a posting not appearing on Usenet but on the Python mail list), etc. etc. ad nauseam, sprinkled with misrepresentations etc. I don't know the point of that. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: * Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. I see we are still all out of step with you. Why did you snip the short argument? Because it's irrelevant and fallacious. If it's a fallacy then I'd like to see a reasoned logical explanation of its fallaciousness. Oh, you snipped it so that you didn't have to present it to readers. That's dishonest, Steve Holden. Requoting: quote Now let's move to the implementation aspects. Python as a language is implemented in many languages. One of these is C. There are compilers to C (pypy), C++ (shedskin), for the JVM (Jython) and .net (Ironpython). There is also an executable operation semantics for python, which can be found here: http://gideon.smdng.nl/2009/01/an-executable-operational-semantics-for-python/ This set of operational semantics is written in Haskell. Haskell is a strictly pure, lazily evaluated language. It therefore has no pointers or references, just values and names. The implementation therefore cannot be in terms of references and pointers. At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote This, if it says anything at all, appears to say that any Turing-complete language has pointers in it, which is an absurdity. As far as I can see, if someone says implementing Python implies the use of pointers as you appear to be doing, then Michael's argument neatly demolishes that argument by providing a counter-example: there is an implementation of Python that does not use pointers. That's meaningless. But then so is maintaining that Python doesn't have references. And so is your argument applied to Pascal, just to mention that again. *You* brought Pascal into this, not me. You, however, dismiss this as a fallacy, and suggests it somehow misrepresents you. And yet you wonder why people call your behavior (not you) paranoid. On top of the multiple fallacies, dubious snipping of arguments, statements that such arguments have not been presented (just after snipping them), and general misleading insinuations and misrepresentation, ad yet another bit of personal attack. Do you understand what that may say to readers about you, Steve Holden? I'm happy to let readers draw their own conclusions about us both. Apparently it's all to defend an indefensible, idiotic position. But I think you're doing it at least partially for the fun of harassing someone. Not at all. You have accused me of bullying behavior, but in truth you are the bully, and we know what happens when you give in to bullies, don't we? [...] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of rambling text. And you can say this without, by your own admission, even reading it. No, you can not quote any place I have said that I haven't read his article. I did read most of it. So you are yet again within the span of one posted article presenting untrue information that you know is not true. I repeat the quote from you which you can read at the top of this post: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] So now you say you read most of it. Even
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: * Michael Sparks: [Due to the appearance of reasoned discussion (it's not practical to read it all!) [...] Therefore to say in reality the implementation will be passing a reference or pointer is invalid. There is after all at least one implementation that does not rely on such machine oriented language details. I'm sorry, but see above: in itself it's just yet another a fallacy. And as an argument in a debate with me it's misrepresenting. I see we are still all out of step with you. Why did you snip the short argument? Because it's irrelevant and fallacious. If it's a fallacy then I'd like to see a reasoned logical explanation of its fallaciousness. Oh, you snipped it so that you didn't have to present it to readers. That's dishonest, Steve Holden. Requoting: quote Now let's move to the implementation aspects. Python as a language is implemented in many languages. One of these is C. There are compilers to C (pypy), C++ (shedskin), for the JVM (Jython) and .net (Ironpython). There is also an executable operation semantics for python, which can be found here: http://gideon.smdng.nl/2009/01/an-executable-operational-semantics-for-python/ This set of operational semantics is written in Haskell. Haskell is a strictly pure, lazily evaluated language. It therefore has no pointers or references, just values and names. The implementation therefore cannot be in terms of references and pointers. At this point consider whether it's possible to implement Pascal in Haskell. If it is possible, then you have a problem wrt. drawing conclusions about pointers in Pascal, uh oh, they apparently can't exist. But if it is not possible to implement Pascal in Haskell, then Haskell must be some etremely limited special-purpose language, not Turing complete -- is that acceptable to you? quote This, if it says anything at all, appears to say that any Turing-complete language has pointers in it, which is an absurdity. As far as I can see, if someone says implementing Python implies the use of pointers as you appear to be doing, then Michael's argument neatly demolishes that argument by providing a counter-example: there is an implementation of Python that does not use pointers. That's meaningless. But then so is maintaining that Python doesn't have references. And so is your argument applied to Pascal, just to mention that again. *You* brought Pascal into this, not me. Of course. And so? Do you think that the/your argument applies to Pascal? Just for your information, it does not work for Pascal. Or any language. It is a fallacy. It does not say anything about Python, or Pascal, or any language. You, however, dismiss this as a fallacy, and suggests it somehow misrepresents you. And yet you wonder why people call your behavior (not you) paranoid. On top of the multiple fallacies, dubious snipping of arguments, statements that such arguments have not been presented (just after snipping them), and general misleading insinuations and misrepresentation, ad yet another bit of personal attack. Do you understand what that may say to readers about you, Steve Holden? I'm happy to let readers draw their own conclusions about us both. I guess you are. For it is invariably so that most readers recall by association, and a flood of flaming does yield an impression. As a technical argument it's a fallacy, but do you care? No. Apparently it's all to defend an indefensible, idiotic position. But I think you're doing it at least partially for the fun of harassing someone. Not at all. You have accused me of bullying behavior, but in truth you are the bully, and we know what happens when you give in to bullies, don't we? After an uncountable number of flames of my person, many from you, I'm the bullied, or victim, so to speak; as such I'm not the bully. [...] I sincerely hope that my reply does not offend or inflame you, since that is not the intent. I do hope it educates you and puts into context the responses you have gained from others. After all, one simply shouting in a corner saying YOU'RE ALL WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT, when one does not to understand what one is talking about does not tend to engender warm fluffy feelings or sentiments of authority towards such an individual. Be it me, you, or anyone else. At the moment, you appear to me to be engaging in such a behaviour. Now you don't know from Jack and probably don't care about my viewpoint, but I would really appreciate it if you would try not to be inflammatory in your response to this. (Since you do appear to also have a need to have the last word) Hoping this was useful on some level, Yes. I elected to respond to just /one/ of the many arguments you presented. The other arguments, about why there are no references in Python, shared, however, the basic property of being logical fallacies packaged in kilometers of
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Howell: This thread is interesting on many levels. What is the core question that is being examined here? I think that regarding the technical it is whether a Python name refers to an object or not. I maintain that it does, and that the reference can be copied, and that the semantics of the language requires this and is defined in terms of this. Steve Holden, D'Aprano and many others maintain that there are no references, or that if there are then they're only an implementation aspect, i.e. that conceiveable one could have an implementation without them. Regarding some other issues it seems to be a childish exercise in flaming, a flame war, with claims of insanity, incompetence, lying (that's actually from me, I reacted a bit strongly to faked quoting + conclusions from that in a posting not appearing on Usenet but on the Python mail list), etc. etc. ad nauseam, sprinkled with misrepresentations etc. I don't know the point of that. It's a pity that no-one has gone far enough to trigger Godwin's Law... ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
In article hl6ilk$f7...@news.eternal-september.org, Alf P. Steinbach al...@start.no wrote: My original statement, with reference to the Java language spec, didn't say much more about the language than that it has assignable references. Assuming this is what you're referring to: Python passes pointers by value, just as e.g. Java does. Then you are simply, completely, totally, and absolutely wrong. Period. Regardless of how CPython manages its state internally, Python as a programming language does not have pointers. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ At Resolver we've found it useful to short-circuit any doubt and just refer to comments in code as 'lies'. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 13, 6:41 pm, a...@pythoncraft.com (Aahz) wrote: In article hl6ilk$f7...@news.eternal-september.org, Alf P. Steinbach al...@start.no wrote: My original statement, with reference to the Java language spec, didn't say much more about the language than that it has assignable references. Assuming this is what you're referring to: Python passes pointers by value, just as e.g. Java does. Then you are simply, completely, totally, and absolutely wrong. Period. Regardless of how CPython manages its state internally, Python as a programming language does not have pointers. I agree with your statement for a suitably narrow definition of the words pointer and have. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 13, 6:10 pm, MRAB pyt...@mrabarnett.plus.com wrote: Alf P. Steinbach wrote: * Steve Howell: This thread is interesting on many levels. What is the core question that is being examined here? I think that regarding the technical it is whether a Python name refers to an object or not. I maintain that it does, and that the reference can be copied, and that the semantics of the language requires this and is defined in terms of this. Steve Holden, D'Aprano and many others maintain that there are no references, or that if there are then they're only an implementation aspect, i.e. that conceiveable one could have an implementation without them. Regarding some other issues it seems to be a childish exercise in flaming, a flame war, with claims of insanity, incompetence, lying (that's actually from me, I reacted a bit strongly to faked quoting + conclusions from that in a posting not appearing on Usenet but on the Python mail list), etc. etc. ad nauseam, sprinkled with misrepresentations etc. I don't know the point of that. It's a pity that no-one has gone far enough to trigger Godwin's Law... ;-) Godwin's Law need not be invoked here. The essential question is relevant and worthy of discussion, and most posters have presented intelligent, nuanced arguments even amidst all the needless flaming. It is actually a subtle point that I think people disagree on, whatever the extraneous personal baggage. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach a écrit : (snip) This group has an extraordinary high level of flaming and personal attacks Oh my... (snip remaining non-sense) Mr Steinbach, I bet you'll count this as another flaming and personal attack, but nonetheless : you might have happier time if you were able to understand the distinction between disagreement and personal attack. (now back to more interesting readings) -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Bruno Desthuilliers: Alf P. Steinbach a écrit : (snip) This group has an extraordinary high level of flaming and personal attacks Oh my... (snip remaining non-sense) Mr Steinbach, I bet you'll count this as another flaming and personal attack, but nonetheless : you might have happier time if you were able to understand the distinction between disagreement and personal attack. (now back to more interesting readings) Yes, I do count this as a personal attack and flaming. The litmus test for that is that it says something very negative about the person you're debating with. In addition, your statement about the earlier attacks on me, is untrue, and your implication that it's only about attacks on me, is untrue. Both of which are very misleading, by the way. I'm assuming that you're intentionally lying. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Fri, 12 Feb 2010 21:26:24 +0100, Alf P. Steinbach wrote: Yes, I do count this as a personal attack and flaming. The litmus test for that is that it says something very negative about the person you're debating with. As negative as accusing somebody of intentionally lying? Or is it only a personal attack when other people dare to disagree with Alf P. Steinbach? In addition, your statement about the earlier attacks on me, is untrue, and your implication that it's only about attacks on me, is untrue. Both of which are very misleading, by the way. I'm assuming that you're intentionally lying. Get over yourself. You're not so important that everyone is falling over themselves to discredit you by intentional lying. You do bring some technical knowledge and perspectives that is valuable to this community, but it comes with so much spikiness, near-paranoia and Freudian projection that it is extremely unpleasant dealing with you. Since you first came to this community, you have displayed a remarkable ability to take personal offence at virtually every disagreement, a deeply paranoid viewpoint that whenever somebody contradicts your statements they are deliberately lying, and a level of arrogance that is outstanding even for computer science. (How sure of yourself do you have to be to write a textbook for beginners in a language that you yourself are a self-professed beginner in?) I note with interest that this is not the only forum where your reaction to disagreement is to accuse others of deliberate lying. It is a habit of yours, and you've displayed it frequently and repeatedly. For example: http://coding.derkeiler.com/Archive/General/comp.programming/2006-08/msg00139.html http://www.embeddedrelated.com/usenet/embedded/show/43780-20.php http://groups.google.am/group/comp.lang.c++/browse_thread/thread/555331f8dd594837 I'm no longer willing to tolerate the unpleasant attitudes you display. So congratulations Alf. I've only kill-filed one other person on this newsgroup until now. You are now the second. I may reverse it some time in the future, but for now I'm just not interested in your paranoid accusations that others are lying about you and your continual misuse of the term ad hominem to refer to any and all criticism of your behaviour. *plonk* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
This thread is interesting on many levels. What is the core question that is being examined here? -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Aahz: In article hl6ilk$f7...@news.eternal-september.org, Alf P. Steinbach al...@start.no wrote: My original statement, with reference to the Java language spec, didn't say much more about the language than that it has assignable references. Assuming this is what you're referring to: Python passes pointers by value, just as e.g. Java does. Then you are simply, completely, totally, and absolutely wrong. Period. Regardless of how CPython manages its state internally, Python as a programming language does not have pointers. The next paragraph was about the meaning of pointer in that first paragraph, referring to the Java language specification for the particular meaning here, namely a reference. Note: I did not refer to CPython, C, Pascal or whatever (but you mention CPython) for a meaning of pointer. Instead I referred to the Java language specification for that meaning, where it's pretty clear: reference. So if you don't like the terminology, you can rephrase with perhaps more palatable terms: Python uses pass by sharing. References to objects are copied, the objects themselves are not copied. See url: http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing If you go to that URL, which isn't auhoritative but good enough, you find that identical semantics in other languages such as Java and Visual Basic Hence, your point is only a matter of terminology. The semantics /can/ be described using the term pointer (or for that matter the term thingamajic), when that term is suitably defined, and it /is/ described using that word for some languages. The language doesn't matter for the concept of pass by sharing. Hence, the terminological issue doesn't invalidate the description, as long as the terminology is clearly defined, as I did with ref to the Java lang spec. As you can see proper terminology reduces the size of explanation considerably, but as I see it that's not a big deal as long as the description is still /reasonably/ short. It does become a concern when the description runs to many pages of text. A simple thing should IMHO be simply described. But I think, as I've already stated several times up-thread, that pointer is a term best avoided for explanations within the Python community, even with a reference to a particular definition/usage, making the more verbose version in terms of references preferable for Python -- don't you agree? Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sat, 13 Feb 2010 18:54:34 -0800, Steve Howell wrote:
On Feb 13, 6:41 pm, a...@pythoncraft.com (Aahz) wrote:
Regardless of how CPython manages its state internally, Python as a
programming language does not have pointers.
I agree with your statement for a suitably narrow definition of the
words pointer and have.
Suitably narrow is not that narrow. By no stretch of the imagination
can one say that Python has a built-in pointer type analogous to pointers
in (say) Pascal or C -- you can't usefully get the address of a variable
(although the CPython implementation leaks the address of objects, it
does so in a way that is safe and useless for everything but a label).
There is no equivalent to (say) the Pascal program:
program main(input, output);
var
x: integer;
ptr: ^integer;
begin
x := 1;
ptr := @x;
ptr^ := ptr^ + 1;
writeln(x);
end.
For a suitably wide definition of pointer, then Python does have
pointers:
data = ['aaa', 'bbb', 'ccc', 'ddd', 'eee']
i = data.index('bbb')
print data[i]
i += 1
data[i] = 'zzz'
but I trust that we all agree that describing the integer offset i above
as a pointer is a reductio ad absurdum.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 13, 7:53 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 13 Feb 2010 18:54:34 -0800, Steve Howell wrote:
On Feb 13, 6:41 pm, a...@pythoncraft.com (Aahz) wrote:
Regardless of how CPython manages its state internally, Python as a
programming language does not have pointers.
I agree with your statement for a suitably narrow definition of the
words pointer and have.
Suitably narrow is not that narrow. By no stretch of the imagination
can one say that Python has a built-in pointer type analogous to pointers
in (say) Pascal or C -- you can't usefully get the address of a variable
(although the CPython implementation leaks the address of objects, it
does so in a way that is safe and useless for everything but a label).
There is no equivalent to (say) the Pascal program:
program main(input, output);
var
x: integer;
ptr: ^integer;
begin
x := 1;
ptr := @x;
ptr^ := ptr^ + 1;
writeln(x);
end.
For a suitably wide definition of pointer, then Python does have
pointers:
data = ['aaa', 'bbb', 'ccc', 'ddd', 'eee']
i = data.index('bbb')
print data[i]
i += 1
data[i] = 'zzz'
but I trust that we all agree that describing the integer offset i above
as a pointer is a reductio ad absurdum.
For a suitably wide definition of pointers CPython does indeed have
pointers, and your example is only a weaker case of that truth. There
is no reductio adsurbum. If I argued that CPython had curly braced
syntax that would be absurd, since it is so concretely wrong.
Pointers are a more abstact concept.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sat, 13 Feb 2010 20:11:06 -0800, Steve Howell wrote:
For a suitably wide definition of pointers CPython does indeed have
pointers, and your example is only a weaker case of that truth. There
is no reductio adsurbum. If I argued that CPython had curly braced
syntax that would be absurd, since it is so concretely wrong. Pointers
are a more abstact concept.
I would argue that your examples are equivalent.
The suitably wide definition of pointers that allows you to argue that
Python has pointers is an implementation detail, just as the
implementation detail that the Python tokenizer uses INDENT and DEDENT
tokens. An INDENT token is just another way of spelling { and DEDENT is
just another way of spelling }, so therefore Python has curly bracket
syntax.
Do I believe this argument is valid? No, of course not, I think it does
so much violence to the concepts of curly brackets and syntax as to be
absurd. Just as I think the only way to justify claiming that Python has
pointers is to do so much violence to the concept of pointer and to
Python's object model as to also be absurd.
That's not to say that the general concept of references (as in to refer
to) isn't valuable when discussing Python. If you want to say that
(e.g.) following
x = 1
the name x refers to (or even points to!) the object 1, my objections
will be mild or non-existent. In that sense, it's probably impossible to
program without some sort of references: the computer manipulates
variables or objects directly, while we manipulate characters in source
code. The only way to write a program is to use some abstract thing (a
name, an offset, whatever) that refers, in some fashion, to a collection
of bits in the computer's memory. But to go from that to the idea that
(say) x is a pointer does so much violence to the concept of pointer and
has so much room for confusion that it is actively harmful.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 13, 9:13 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 13 Feb 2010 20:11:06 -0800, Steve Howell wrote:
For a suitably wide definition of pointers CPython does indeed have
pointers, and your example is only a weaker case of that truth. There
is no reductio adsurbum. If I argued that CPython had curly braced
syntax that would be absurd, since it is so concretely wrong. Pointers
are a more abstact concept.
I would argue that your examples are equivalent.
The suitably wide definition of pointers that allows you to argue that
Python has pointers is an implementation detail, just as the
implementation detail that the Python tokenizer uses INDENT and DEDENT
tokens. An INDENT token is just another way of spelling { and DEDENT is
just another way of spelling }, so therefore Python has curly bracket
syntax.
You seem to be missing the point that curly braces is a concrete
term that very specifically applies to spelling.
Do I believe this argument is valid? No, of course not, I think it does
so much violence to the concepts of curly brackets and syntax as to be
absurd. Just as I think the only way to justify claiming that Python has
pointers is to do so much violence to the concept of pointer and to
Python's object model as to also be absurd.
That's not to say that the general concept of references (as in to refer
to) isn't valuable when discussing Python. If you want to say that
(e.g.) following
x = 1
the name x refers to (or even points to!) the object 1, my objections
will be mild or non-existent. In that sense, it's probably impossible to
program without some sort of references: the computer manipulates
variables or objects directly, while we manipulate characters in source
code. The only way to write a program is to use some abstract thing (a
name, an offset, whatever) that refers, in some fashion, to a collection
of bits in the computer's memory. But to go from that to the idea that
(say) x is a pointer does so much violence to the concept of pointer and
has so much room for confusion that it is actively harmful.
I agree that reference is a much better term than pointer.. It has
the right amount of generalness in my opinion. I think violence is a
bit overstated, but your bigger point is well taken and it seems like
reference is useful middle ground between pure cpython language and
misrepresentative analogy.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Sat, 13 Feb 2010 21:33:50 -0800, Steve Howell wrote: You seem to be missing the point that curly braces is a concrete term that very specifically applies to spelling. And you seem to be missing the point that pointer is also a concrete term that very specifically applies to, well, pointers. [...] I agree that reference is a much better term than pointer.. It has the right amount of generalness in my opinion. I think violence is a bit overstated, but your bigger point is well taken and it seems like reference is useful middle ground between pure cpython language and misrepresentative analogy. But reference also has a concrete meaning: C++ has a type explicitly called reference: http://en.wikipedia.org/wiki/Reference_(C++) And of course call-by-reference (or pass-by-reference) has a specific, technical meaning. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Sat, 13 Feb 2010 21:33:50 -0800, Steve Howell wrote: You seem to be missing the point that curly braces is a concrete term that very specifically applies to spelling. And you seem to be missing the point that pointer is also a concrete term that very specifically applies to, well, pointers. [...] I agree that reference is a much better term than pointer.. It has the right amount of generalness in my opinion. I think violence is a bit overstated, but your bigger point is well taken and it seems like reference is useful middle ground between pure cpython language and misrepresentative analogy. But reference also has a concrete meaning: C++ has a type explicitly called reference: http://en.wikipedia.org/wiki/Reference_(C++) And of course call-by-reference (or pass-by-reference) has a specific, technical meaning. Hm. Consider your argument about reference being possible to confuse with pass by reference in the light of pass by name, used by Algol, url: http://en.wikipedia.org/wiki/Jensen%27s_Device. Oops, to consistently remove all possible ambiguity the term name can't be used about formal arguments. I think, even though pass by name is much less well known than pass by reference, this indicates that it's not practically possible to remove all possible ambiguity. I think some Common Sense(TM) must in any case be assumed, and applied. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Feb 13, 11:21 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sat, 13 Feb 2010 21:33:50 -0800, Steve Howell wrote:
You seem to be missing the point that curly braces is a concrete
term that very specifically applies to spelling.
And you seem to be missing the point that pointer is also a concrete
term that very specifically applies to, well, pointers.
The term pointer is very abstract. Please give me a concrete
definition of a pointer.
A curly brace is one of these: { }
Pretty concrete, I hope.
[...]
I agree that reference is a much better term than pointer.. It has
the right amount of generalness in my opinion. I think violence is a
bit overstated, but your bigger point is well taken and it seems like
reference is useful middle ground between pure cpython language and
misrepresentative analogy.
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.
And of course call-by-reference (or pass-by-reference) has a specific,
technical meaning.
Which is what?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
cut all Well at least you are well written and more subtle than Xah Lee. Though I find him also quite amusing, I do like a good flame-war every now and again, and in that perspective I solute you. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Hi Alf, Before I start, note we're talking about semantics, not implementation. That distinction is very important. On Feb 11, 4:49 am, Alf P. Steinbach al...@start.no wrote: *The* standard general language independent definition? [ of pointer ] Yes. As defined where? For example, as I used as reference in my first posting, the Java language spec. But it has nothing specifically to do with Java. It is a basic concept in computer science, that (most) CS students learn in their *first year*. E.g. quote src=http://cslibrary.stanford.edu/106/; A pointer stores a reference to something. Unfortunately there is no fixed term for the thing that the pointer points to, and across different computer languages there is a wide variety of things that pointers point to. We use the term pointee for the thing that the pointer points to, and we stick to the basic properties of the pointer/pointee relationship which are true in all languages. The term reference means pretty much the same thing as pointer -- reference implies a more high-level discussion, while pointer implies the traditional compiled language implementation of pointers as addresses. For the basic pointer/pointee rules covered here, the terms are effectively equivalent. /quote This is where you have gone wrong. You have taken a first year undergraduate academic generalisation and assumed that it applies to The World. In theory, there is no difference between practice and theory, but in practice there is (so the saying goes). The World however has another place for defining terms. That place is of highly varying quality, but generally a better place to correct semantics of terms. Who knows, eventually there may be a single commonly accepted viewpoint. (Which would bring a whole new level of pedantry of course )-: I am referring to Wikipedia here. (this is a vague attempt at humour, rather than an attempt to patronise which it may also come over as) Let's look at the tip of the iceberg for that: In computer science, a pointer is a programming language data type whose value refers directly to (or points to) another value stored elsewhere in the computer memory using its address. http://en.wikipedia.org/wiki/Pointer_%28computing%29 Similarly for Call by Value: (which *is* a loaded term) In call-by-value, the argument expression is evaluated, and the resulting value is bound to the corresponding variable in the function (frequently by copying the value into a new memory region). If the function or procedure is able to assign values to its parameters, only its local copy is assigned — that is, anything passed into a function call is unchanged in the caller's scope when the function returns. http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_value Call by Reference: (again, loaded term): In call-by-reference evaluation (also referred to as pass-by- reference), a function receives an implicit reference to the argument, rather than a copy of its value. This typically means that the function can modify the argument- something that will be seen by its caller. http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference Call by Sharing: (far less common term) Also known as call by object or call by object-sharing is an evaluation strategy first named by Barbara Liskov et al. for the language CLU in 1974[1]. It is used by languages such as Python[2], Iota, Java (for object references)[3], Ruby, Scheme, OCaml, AppleScript, and many other languages. The semantics of call-by-sharing differ from call-by-reference in that assignments to function arguments within the function aren't visible to the caller (unlike by-reference semantics). http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing As you can see, there are generally accepted terms and definitions here, and python is accepted as falling not into the value or reference camp, along with some other languages. Understanding why IMO comes back to some basic aspects of python which I believe trip up experienced developers. This claim is based on talking to someone experienced in coding for a couple of decades, who has done a CS degree (like me), and just didn't understand why I would use python. I spent an couple of _days_ explaining this, along with python's evaluation model, and at the end we ended up where we started: * Python is a language which is focussed on programmer performance, not machine performance, because relative to programmer cost, machines are cheap. Therefore you focus your language to optimise for the programmer, not the machine. In this case, let's drop back to the word pointer which I can understand that you like. Indeed, it took me a fair while to let go of the word when talking about python, but you do have to. Why? Well, assume this definition isn't bad: In computer science, a pointer is
Re: Modifying Class Object
* Michael Sparks: Hi Alf, Before I start, note we're talking about semantics, not implementation. That distinction is very important. Yes. It would seem to readers that posters here do not grasp and are unable to grasp that distinction. However, all those references to implementation aspects, persisting in the face of corrections, have just, IMHO, been consistent attempts at misrepresentation. On Feb 11, 4:49 am, Alf P. Steinbach al...@start.no wrote: *The* standard general language independent definition? [ of pointer ] Yes. As defined where? For example, as I used as reference in my first posting, the Java language spec. But it has nothing specifically to do with Java. It is a basic concept in computer science, that (most) CS students learn in their *first year*. E.g. quote src=http://cslibrary.stanford.edu/106/; A pointer stores a reference to something. Unfortunately there is no fixed term for the thing that the pointer points to, and across different computer languages there is a wide variety of things that pointers point to. We use the term pointee for the thing that the pointer points to, and we stick to the basic properties of the pointer/pointee relationship which are true in all languages. The term reference means pretty much the same thing as pointer -- reference implies a more high-level discussion, while pointer implies the traditional compiled language implementation of pointers as addresses. For the basic pointer/pointee rules covered here, the terms are effectively equivalent. /quote This is where you have gone wrong. You have taken a first year undergraduate academic generalisation and assumed that it applies to The World.' I'm sorry to disappoint, but no. It was a random Google hit to find a first-year text that perhaps posters here could understand. Not insinuiting anything about their mental prowess or lack thereof, but just something they might understand given a repeatedly demonstrated inability to understand such basics, or even to understand the concept of reference to a definition of a term. Please do consider that my usage of the term pointer has always, in this thread, including the first article I posted in this thread, been with explicit reference to the Java language spec's meaning. You may argue that those who wrote that language spec are confused about things or whatever, but that's rather stretching it, wouldn't you say? In theory, there is no difference between practice and theory, but in practice there is (so the saying goes). The World however has another place for defining terms. That place is of highly varying quality, but generally a better place to correct semantics of terms. Who knows, eventually there may be a single commonly accepted viewpoint. (Which would bring a whole new level of pedantry of course )-: I am referring to Wikipedia here. (this is a vague attempt at humour, rather than an attempt to patronise which it may also come over as) I understand. You may note that that Wikipedia article refers to an article that I wrote about pointers in C++. So, this must be the most silly argument by authority ever offered. I find that amusing and would have included a smiley except that I think that that would incur further flames. It's no criticism of you; I do appreciate your effort, thanks. And I reiterate that the meaning of pointer I have used is the meaning in the Java language spec. And that that's about semantics, not about implementation, and not about C pointers or Pascal pointers or whatever else that some would rather wish it was. [snip] In the following that I snipped you had good discussion except for (as I could see) a fallacy-based denial of references existing in Python. I don't think there's any point in discussing that further, because it's evidently a religious matter where rational arguments -- and I've tried a few -- don't reach, in spite of the extreme triviality of the subject matter. Thanks for the effort at non-flaming discussion, it *is* appreciated. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: You may note that that Wikipedia article refers to an article that I wrote about pointers in C++. It's a broken link, referring to a non-existent server. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: You may note that that Wikipedia article refers to an article that I wrote about pointers in C++. It's a broken link, referring to a non-existent server. Yes, sorry. It's been that way a long time, and for the same reason my C++ tutorial, the only one linked to from the C++ FAQ, is also off-line. However, if you're interested then copies of the pointers doc are likely to be floating around (at one time some mention of it somewhere generated very high traffic over a few weeks, people downloading the PDF, and then I almost reversed my decision not to have ads...). Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Fri, 12 Feb 2010 21:26:24 +0100, Alf P. Steinbach wrote: Yes, I do count this as a personal attack and flaming. The litmus test for that is that it says something very negative about the person you're debating with. As negative as accusing somebody of intentionally lying? Or is it only a personal attack when other people dare to disagree with Alf P. Steinbach? Do you mean that everybody else is allowed to get personal, but I, in return, am not so allowed? In addition, your statement about the earlier attacks on me, is untrue, and your implication that it's only about attacks on me, is untrue. Both of which are very misleading, by the way. I'm assuming that you're intentionally lying. Get over yourself. You're not so important that everyone is falling over themselves to discredit you by intentional lying. This implies something about my beliefs about my importance, that is, it is clearly intended as an ad hominem attack. I'm getting a bit tired of that. You do bring some technical knowledge and perspectives that is valuable to this community, but it comes with so much spikiness, near-paranoia and Freudian projection that it is extremely unpleasant dealing with you. Since you first came to this community, you have displayed a remarkable ability to take personal offence at virtually every disagreement, That is not true. I do take offense at pure personal attacks, though. Personal attacks are about person, technical discussion is about technical things. a deeply paranoid viewpoint that whenever somebody contradicts your statements they are deliberately lying, That's just stupid, sorry. Being paranoid is not about being attacked, or about pointing out when someone's lying. Hello. and a level of arrogance that is outstanding even for computer science. (How sure of yourself do you have to be to write a textbook for beginners in a language that you yourself are a self-professed beginner in?) I note with interest that this is not the only forum where your reaction to disagreement is to accuse others of deliberate lying. Your argument gets a bit circular. It is a habit of yours, That is untrue. and you've displayed it frequently No, that is untrue. and repeatedly. Yes, I have repeatedly pointed when people have been lying, citing the evidence and logic leading to that conclusion. I wouldn't just accuse someone of something like that. It's far too serious (however, above you're happy with accusing me of being paranoid and whatever, so I conclude that you have no such qualms). For example: http://coding.derkeiler.com/Archive/General/comp.programming/2006-08/msg00139.html http://www.embeddedrelated.com/usenet/embedded/show/43780-20.php http://groups.google.am/group/comp.lang.c++/browse_thread/thread/555331f8dd594837 Yes, I've been on the net a long time, and consequently I have been involved in flame wars. :-)[1] That is no excuse for your behavior. An extremely long thread dedicated to the notion that there are no references in Python (which is blatantly false), coupled with personal attacks on the one person arguing that there are. I could easily think that you were having me on. Of course most anyone else who'd hold the rational opinion would not join the battlefield, because it clearly wasn't and isn't about convincing or educating anyone, but I feel that follow-ups to my articles should be answered. Cheers hth., - Alf Notes: [1] Like one here where some guy A objects to some other guy B's use of the term portable assembler about C, where at first I try to defend B's point of view, since it is after all one employed even by the creators of C. B sensibly opts out of the discussion while I stay on, predictable result. Another flame war is with some functional programming fanatic, and a third with a known troll. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: [...] Of course most anyone else who'd hold the rational opinion would not join the battlefield, because it clearly wasn't and isn't about convincing or educating anyone, but I feel that follow-ups to my articles should be answered. In other words, you must have the last word, a behavioral characteristic I will avoid drawing the obvious conclusions about for fear of begin accused (yet again) of making ad hominem attacks. I suppose you will therefore be unable to resist the temptation to respond to this. Though I'd love to be proved wrong again. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steven D'Aprano: On Fri, 12 Feb 2010 21:26:24 +0100, Alf P. Steinbach wrote: Yes, I do count this as a personal attack and flaming. The litmus test for that is that it says something very negative about the person you're debating with. As negative as accusing somebody of intentionally lying? Or is it only a personal attack when other people dare to disagree with Alf P. Steinbach? Do you mean that everybody else is allowed to get personal, but I, in return, am not so allowed? In addition, your statement about the earlier attacks on me, is untrue, and your implication that it's only about attacks on me, is untrue. Both of which are very misleading, by the way. I'm assuming that you're intentionally lying. Get over yourself. You're not so important that everyone is falling over themselves to discredit you by intentional lying. This implies something about my beliefs about my importance, that is, it is clearly intended as an ad hominem attack. I'm getting a bit tired of that. You do bring some technical knowledge and perspectives that is valuable to this community, but it comes with so much spikiness, near-paranoia and Freudian projection that it is extremely unpleasant dealing with you. Since you first came to this community, you have displayed a remarkable ability to take personal offence at virtually every disagreement, That is not true. I do take offense at pure personal attacks, though. Personal attacks are about person, technical discussion is about technical things. a deeply paranoid viewpoint that whenever somebody contradicts your statements they are deliberately lying, That's just stupid, sorry. Being paranoid is not about being attacked, or about pointing out when someone's lying. Hello. and a level of arrogance that is outstanding even for computer science. (How sure of yourself do you have to be to write a textbook for beginners in a language that you yourself are a self-professed beginner in?) I note with interest that this is not the only forum where your reaction to disagreement is to accuse others of deliberate lying. Your argument gets a bit circular. It is a habit of yours, That is untrue. and you've displayed it frequently No, that is untrue. and repeatedly. Yes, I have repeatedly pointed when people have been lying, citing the evidence and logic leading to that conclusion. I wouldn't just accuse someone of something like that. It's far too serious (however, above you're happy with accusing me of being paranoid and whatever, so I conclude that you have no such qualms). For example: http://coding.derkeiler.com/Archive/General/comp.programming/2006-08/msg00139.html http://www.embeddedrelated.com/usenet/embedded/show/43780-20.php http://groups.google.am/group/comp.lang.c++/browse_thread/thread/555331f8dd594837 Yes, I've been on the net a long time, and consequently I have been involved in flame wars. :-)[1] That is no excuse for your behavior. An extremely long thread dedicated to the notion that there are no references in Python (which is blatantly false), coupled with personal attacks on the one person arguing that there are. I could easily think that you were having me on. Of course most anyone else who'd hold the rational opinion would not join the battlefield, because it clearly wasn't and isn't about convincing or educating anyone, but I feel that follow-ups to my articles should be answered. Cheers hth., - Alf Notes: [1] Like one here where some guy A objects to some other guy B's use of the term portable assembler about C, where at first I try to defend B's point of view, since it is after all one employed even by the creators of C. B sensibly opts out of the discussion while I stay on, predictable result. Another flame war is with some functional programming fanatic, and a third with a known troll. I'm intrigued by your comments over the last couple of weeks, as you obviously know so much more about Python than people who have been working on it and/or using it for the 20 odd years of the existence of the language. Is it safe to assume that shortly you will be telling the scientific community that Einstein was a complete bozo and that his theory of relativity is crap, or that Stephen (Bob?) Hawking knows nothing about the origins of the universe? To put it another way, please stand up Alf, your voice is rather muffled. And this isn't an ad hominem attack, whatever the hell that means, I (NOTE I ) personally wish you'd bugger off and leave the bandwidth to people who genuinely want to discuss Python, computing algorithms, whatever. And please do NOT bother to reply. Your pathetic smileys and/or HTH garbage cut no ice with me. I'm quite simply staggered that the Python community as a whole have shown far more patience than I have, otherwise you'd have been shot down in seriously bad flames days ago. To you, Alf, get
Re: Modifying Class Object
* Mark Lawrence: Alf P. Steinbach wrote: An extremely long thread dedicated to the notion that there are no references in Python (which is blatantly false), coupled with personal attacks on the one person arguing that there are. I could easily think that you were having me on. Of course most anyone else who'd hold the rational opinion would not join the battlefield, because it clearly wasn't and isn't about convincing or educating anyone, but I feel that follow-ups to my articles should be answered. [snippety] I'm intrigued by your comments over the last couple of weeks, as you obviously know so much more about Python than people who have been working on it and/or using it for the 20 odd years of the existence of the language. I don't. On the other hand, it's a fallacy to think other people must be perfect. The glossary of my Python 3.1.1 documentation defines Reference count: The number of references to an object. [...] And so arguing against the existence of assignable references in Python would be silly if it was a genuine technical discussion. But I suspect that, in spite of my /first article's/ reference and frequent later references to term definitions etc., many who posted in this thread thought they were arguing against some other point of view, in the frenzy not bothering to check out things or actually /read/ what they replied to. So, as demonstrated, assuming that you were referring to people participating in this thread, people who have used a language for 20 odd years can still be wrong about something -- even when that something is utterly trivial. Is it safe to assume that shortly you will be telling the scientific community that Einstein was a complete bozo and that his theory of relativity is crap, or that Stephen (Bob?) Hawking knows nothing about the origins of the universe? To put it another way, please stand up Alf, your voice is rather muffled. And this isn't an ad hominem attack Your response *is not* a personal attack? Then why are you trying to imply all kinds of things about my person, and not mentioning anything technical? Is there anything in the above, about assignable references, that you really think is on a par with relativity and requires Einstein's genius to understand? , whatever the hell that means, I (NOTE I ) personally wish you'd bugger off and leave the bandwidth to people who genuinely want to discuss Python, computing algorithms, whatever. And please do NOT bother to reply. Your pathetic smileys and/or HTH garbage cut no ice with me. I'm quite simply staggered that the Python community as a whole have shown far more patience than I have, otherwise you'd have been shot down in seriously bad flames days ago. To you, Alf, get stuffed. Are you sure that this is not a personal attack? Just curious how you manage to think it couldn't be. Cheers hth., ;-) - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
This entire thread has imploded like a neutron star into an infantile debate that only Caddie Couric, Bill O Reilly, and everyone on PMS-NBC can hold a candle to! The only post i enjoyed was Steve Howes! From my unique perspective of not really knowing (or for that matter) really caring about any of you i can say *some* of you have most undoubly shown your true colors in this thread! First of all, we all know how D Aprano has such an unfettered ego problem. I myself have been the victom of his insults but simultaniously also found them quite enjoyable (at times) I'd classify Steven d'Aprano as a well informed arsehole with an inner clown trying to escape. Then there is alex23. The only sockpuppet (of many suspects within this group) that i can 100 percent prove and of whom i knew sooner or later would come along for his chance at trolling. Just look at his GG cache and you will see 99% of his post are argmentitve, abusive trolls! He's a fish that waits for threads like these just so he can flop around! As for Alf, no he is not *tecnically* right about the definition of ad homine but that *really* doesn't matter. He has (time and time again) been personally attacked by some of the more supposedly respected people in this group. And as always the roaches start coming out of the woodwork in a most pathetic puppy dog way. What would you puppets do if there were no one to pull your strings? But the most nortoriuos behavior of all belongs to none other that the PSF chairman himself! Yes Steve Holden, you should be ashamed of yourself! Your attacks have been more amd more destructive over the past year or so. Even if your behavoir could somehow be justified how can someone in your position lead the PSF and act as such an infintile way? I am very ashamed of you Steve and you really owe Alf (and the community at large) an apology although i doubt it will happen because then your own people will turn against you. I have documented the bad behavours of certain pythonistas on this group for some time now. And my original assumtions that only a handful of people really follow this group. Maybe one day we will have a fair playing feild for all but sadly it looks to be more like a pipe dream! Sleep well kids! -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* I V: On Thu, 11 Feb 2010 07:37:35 +0100, Alf P. Steinbach wrote: * Steven D'Aprano: s = [1] t = s # Binds the name t to the object bound to the name s. t[0] = 2 # Changes the object bound to the name t print(s) # Checks the object via the original name. Notice that your version describes what happens according to some implementation, below the level of the Python virtual machine. Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? If it doesn't, then it has no effect whatsoever. But since it does have an effect, a memory change has been effected. I don't think your disagreeing with Steven here - by talking about the computers memory, it's clear that you are talking about the details of an implementation of python, not the semantics of python itself. Unless, of course, you are under the misapprehension that the computer's memory is relevant to the python language, rather than the particular implementation. Python itself has nothing to do with computers or memory; these are mere implementation details. You know, the programming language that doesn't need computers: Python. :-) Cheers, - Alf (not sure how to read your posting, but it's funny anyhow) -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach al...@start.no writes: [...] That's bullshit. [...] not any that you know about. [...] yet another ad hominem attack [...] It also reflects rather badly on you. [...] - Alf Alf, The above was extracted from the last post from you but I could have picked almost any of your recent endeavours. I've come to the conclusion that you're not a cute furry alien with a long nose. You're a big bad troll! -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Holden: [...] In this particular part of the thread I am attempting, unsuccessfully, to convince you that a change in *your* behavior would lead to less hostility directed towards the way you present your ideas. You apparently feel it is quite acceptable to tell people to learn to read, I have not used that expression. However I have suggest and emphasized that it might help to *read* whatever one quotes, when the quoted material (such as one paragraph) has not been read. Telling someone to learn to read is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Telling a person to read something that's obviously not been read is quite another matter. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. Pardon me? You used it on December 16 in a response to Mensanator in message hgbri8$e1...@news.eternal-september.org M : How about devoting a section on downloading the source files M : and compiling it on a Mac? AS: Learn to read. AS: At the top of every second page it tells you that this is an AS: introduction based on Windows. I am sure you will have some glib response as to why this wasn't rude at all. Allow me to correct you - it was, and rudeness is not welcomed on comp.lang.python. That doesn't mean it doesn't happen (why, I have even been known to be rude myself - we are none of us perfect, after all). I have already given ample evidence that when I am wrong I will admit it. You, contrariwise, maintain that you will admit when you are wrong (I believe 40% of the time was the figure you used) but I fail to remember any single incident when you made such an admission. and calling their assertions bullshit, Yes, in this group, but only for personal attacks. Such as yours. I think I've shown extreme restraint in the face of bullying from you and some followers, and calling the insinuations bullshit is quite mild. I don't have followers. Assertions I make are my own, and stand alone without the need of support. Calling them bullshit is indeed quite mild, but doesn't invalidate them. You can only do that by engaging, but instead you hysterically shout ad hominem whenever anyone makes a personal remark. but when we try to point out aspects of your behavior that are either undesirable or unacceptable we are indulging in ad hominem attacks. That is an untrue and extremely misleading description of what you've been doing. I'll let that be judged on the record. You have consistently refused to accept, despite assertions from several individuals (presumably those you choose to characterize as my followers, thereby allowing you to write them off without seriously considering what they say - at least that is how it looks from the outside) that criticism of your behavior is not, in fact, an ad hominem attack but an attempt to engage you in debate and have you modify that behavior. So, for the final time: remarks about personal characteristics only constitute ad hominem attacks ONLY when they are made for the purpose of invalidating other (typically, in this group, technical) arguments. If we met in person at a conference (God help us both) and you sat in an open space session picking your nose, would you deem it an ad hominem attack if I told you to stop? It sounds like it, even though I would tell you to stop not so that others would respect your technical arguments any less, but because by departing from the accepted standards of behavior you would offend others. In your terms, your accusing me of bullying behavior is an ad hominem attack on me, so I won't bother to respond further. You're complaining about the person you're hitting saying clearly what you did. If some truthful words about bullying can get you straight I'm for it. Even if it means getting down to your level (and yes, I did). Nope, I'm not complaining at all. That's your tactic: look, Steve is hitting me. You are entitled to write what you like on this newsgroup, but you have to accept that it will have consequences. I am simply pointing out that what's sauce for the goose is sauce for the gander. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steven D'Aprano: [...] accusing them of lying for having an opinion that differs from yours, That is untrue. Well, that says it all really. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Steven D'Aprano: [...] accusing them of lying for having an opinion that differs from yours, That is untrue. Well, that says it all really. You seem to insinuate that I'm saying that Steven is lying, and/or that Steven is lying. From context and your earlier similar behavior, I presume the former only. Anyway that's a *very* dirty insinuation. And ... It seems you *do not understand* the difference between an incorrect statement and a lie. Which is very telling, I'm sorry. And you have yet again concentrated on a personal attack via insinuation etc., diversion, which also is very telling, sorry. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Steve Holden: [...] In this particular part of the thread I am attempting, unsuccessfully, to convince you that a change in *your* behavior would lead to less hostility directed towards the way you present your ideas. You apparently feel it is quite acceptable to tell people to learn to read, I have not used that expression. However I have suggest and emphasized that it might help to *read* whatever one quotes, when the quoted material (such as one paragraph) has not been read. Telling someone to learn to read is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Telling a person to read something that's obviously not been read is quite another matter. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. Pardon me? You used it on December 16 in a response to Mensanator in message hgbri8$e1...@news.eternal-september.org M : How about devoting a section on downloading the source files M : and compiling it on a Mac? AS: Learn to read. AS: At the top of every second page it tells you that this is an AS: introduction based on Windows. I am sure you will have some glib response as to why this wasn't rude at all. Allow me to correct you - it was, and rudeness is not welcomed on comp.lang.python. That doesn't mean it doesn't happen (why, I have even been known to be rude myself - we are none of us perfect, after all). I have already given ample evidence that when I am wrong I will admit it. You, contrariwise, maintain that you will admit when you are wrong (I believe 40% of the time was the figure you used) No, 40% of contested cases. But that was sort of a white lie. I'm not that often wrong, and anyway it doesn't apply to me in [comp.lang.python] so far. It only applies to groups where only things that might be incorrect are challenged. but I fail to remember any single incident when you made such an admission. Your memory seems to be very very bad, since I've stated I've been wrong also in direct debates with you. But one person who /does/ have severe trouble admitting that he's wrong, going to the extreme of ad hominem attacks and using terms such as wring to avoid saying it (it's quite amazing, almost unbelievable) is Steve Holden. Anyway, I was wrong about not having used that phrase learn to read. I'm not sure if I ever apologized directly to Mensanator for that, and now it's history, but what I do know I did was to follow up on that comment of his, making changes, and to acknowledge him for that in the [ack.txt] listing. Any reader might draw conclusions from that, e.g. what I positively did or what I possibly forgot to do -- we're not perfect beings any of us. [Steve Holden rambling with personal characterizations circular logic snipped] Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On 2/11/2010 1:37 AM, Alf P. Steinbach wrote: Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? By 'computer', do you mean 'anything that computes' (including humans) or specifically 'electronic computer'? But since it does have an effect, a memory change has been effected. Agreed, in whatever 'memory' the 'computer' is using. You describe that memory change as that t has been bound to the same object as s. I prefer to use the word 'associated': namespaces are a many-to-one association between names and objects. By which you mean that henceforth, until the next assignment to t, t *refers* to the same object as s. T and s are both associated with the same object. That explanation in terms of refers is necessary. I disagree No beginner knows what it means that a name is bound to something means, until it's been explained. I agree, which is why I am trying to avoid 'bound', etc, in favor of 'associated'. One problem of 'bind' is that it sometimes raises the question of which is bound to which. 'Associated' avoids that. The explanation is necessarily in terms of refers to. I have given an alternative, even if you still prefer yours. When something A refers to something B, then by definition A is a *reference* to B. I presume you agree that the name 'Alf P. Steinbach' refers to you. Do you then consider it to be a 'reference' to you? In either case, the Python definition uses 'refers to' in the same way that names refer to people, and did even before names were used in electro-mechanical computer programming. Steven D'Aprano: My version describes what happens at the level of high-level Python code, which is the defined semantics of the language. It makes no assumptions about the implementation, completely unlike yours which is entirely implementation- specific. My description is equally valid whether Python is being executed by the CPython virtual machine on an Intel-compatible processor, or hand-simulated with pencil and paper, or something completely different. Yours is not. About 13 years ago, I noticed that electronically executable Python was very similar to some of the designed-for-human-reading algoritm languages (pseudocode) that were not. I then coined the oxymoron 'executable pseudocode' for Python. I see the difference between the descriptions as reflecting the difference between Python, the executable algorithm language and Python, the machine programming language. I describe the high-level language, you describe one implementation. Neither view is *wrong*, per se, but one describes the semantics of the language while the other describes the implementation. I think anyone writing books using Python should at least understand the abstract view even if he prefers to write from the more concrete view. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Terry Reedy: On 2/11/2010 1:37 AM, Alf P. Steinbach wrote: Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? By 'computer', do you mean 'anything that computes' (including humans) or specifically 'electronic computer'? In this context I mean the virtual machine that a Python language assumes. Doesn't matter if it's electronic or a pen-and-pencil simulation. But since it does have an effect, a memory change has been effected. Agreed, in whatever 'memory' the 'computer' is using. You describe that memory change as that t has been bound to the same object as s. I prefer to use the word 'associated': namespaces are a many-to-one association between names and objects. By which you mean that henceforth, until the next assignment to t, t *refers* to the same object as s. T and s are both associated with the same object. That explanation in terms of refers is necessary. I disagree No beginner knows what it means that a name is bound to something means, until it's been explained. I agree, which is why I am trying to avoid 'bound', etc, in favor of 'associated'. One problem of 'bind' is that it sometimes raises the question of which is bound to which. 'Associated' avoids that. The explanation is necessarily in terms of refers to. I have given an alternative, even if you still prefer yours. Associated is just less precise than refers. Associated is two-way. Anyway it's just a term, and if you define it to mean a one-way reference, then nothing substantial is changed except more room for misunderstanding. When something A refers to something B, then by definition A is a *reference* to B. I presume you agree that the name 'Alf P. Steinbach' refers to you. Do you then consider it to be a 'reference' to you? Yes, and that's irrelevant, because you can't change a name. It's a slightly different meaning. But a name edit field with my name in it most probably refers to me. In either case, the Python definition uses 'refers to' in the same way that names refer to people, and did even before names were used in electro-mechanical computer programming. That's so subtle a distinction that it appears meaningless to me. It says refers to but doesn't mean refers to? Steven D'Aprano: My version describes what happens at the level of high-level Python code, which is the defined semantics of the language. It makes no assumptions about the implementation, completely unlike yours which is entirely implementation- specific. My description is equally valid whether Python is being executed by the CPython virtual machine on an Intel-compatible processor, or hand-simulated with pencil and paper, or something completely different. Yours is not. About 13 years ago, I noticed that electronically executable Python was very similar to some of the designed-for-human-reading algoritm languages (pseudocode) that were not. I then coined the oxymoron 'executable pseudocode' for Python. I see the difference between the descriptions as reflecting the difference between Python, the executable algorithm language and Python, the machine programming language. I describe the high-level language, you describe one implementation. Neither view is *wrong*, per se, but one describes the semantics of the language while the other describes the implementation. I think anyone writing books using Python should at least understand the abstract view even if he prefers to write from the more concrete view. It seems to me that you lack an understanding of the abstract here, going into imagined and not concretely discussed differences between refers to and refers to. Until or if (but I think it unlikely) you can explain clearly what that difference between refers to and refers to is, it's just wordplay. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Thu, 11 Feb 2010 17:11:17 -0500, Terry Reedy wrote: About 13 years ago, I noticed that electronically executable Python was very similar to some of the designed-for-human-reading algoritm languages (pseudocode) that were not. I then coined the oxymoron 'executable pseudocode' for Python. That was yours? Nice one! -- Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Thu, 11 Feb 2010 23:26:34 +0100, Alf P. Steinbach wrote: I presume you agree that the name 'Alf P. Steinbach' refers to you. Do you then consider it to be a 'reference' to you? Yes, and that's irrelevant, because you can't change a name. Pardon me, but you most certainly can. Even Germany, which doesn't allow people to change their legal name for frivolous reasons, makes exceptions and will allow people to change their name if (e.g.) they have a sex change, or if they are burdened with a name that causes them ridicule, and presumably for their equivalent of the witness relocation program. And even Germany doesn't presume to tell people what name they are known by to their friends and family. In Python, one can't change names *in place*, because strings are immutable. (Although I have seen a hack with ctypes which allows you to modify string objects. It makes a nice trick, but is completely useless because of the side-effects.) Even if you could modify the name, that would break the namespace it was stored in. But of course you can change names in two steps: x = something() y = x del x And lo, we have changed the name x to y. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Thu, 11 Feb 2010 23:26:34 +0100, Alf P. Steinbach wrote: I presume you agree that the name 'Alf P. Steinbach' refers to you. Do you then consider it to be a 'reference' to you? Yes, and that's irrelevant, because you can't change a name. Pardon me, but you most certainly can. Even Germany, which doesn't allow people to change their legal name for frivolous reasons, makes exceptions and will allow people to change their name if (e.g.) they have a sex change, or if they are burdened with a name that causes them ridicule, and presumably for their equivalent of the witness relocation program. And even Germany doesn't presume to tell people what name they are known by to their friends and family. In Python, one can't change names *in place*, because strings are immutable. (Although I have seen a hack with ctypes which allows you to modify string objects. It makes a nice trick, but is completely useless because of the side-effects.) Even if you could modify the name, that would break the namespace it was stored in. But of course you can change names in two steps: x = something() y = x del x And lo, we have changed the name x to y. Good joke. :-) Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Martin P. Hellwig: cut all Well at least you are well written and more subtle than Xah Lee. Though I find him also quite amusing, I do like a good flame-war every now and again, and in that perspective I solute you. The technical discussion is now at point where one poster maintains that references don't exist in Python, and another poster, in support, maintains that refers to in the language spec doesn't mean refers to but instead means refers to, whatever's that meant to mean. As a technical discussion it's meaningless drivel. And as an argument in that technical discussion your allegation of trolling is just yet another fallacy, and meaningless. But in a social context, declaring support or placing oneself within a group, or for that matter Poisoning the well, it can make sense. This group has an extraordinary high level of flaming and personal attacks, and it's the only group I've seen where there are threads (I think I've seen 3, within the last two months, not participating in them) with the regulars reitererating how friendly the group is, how difficult it is to get flamed here. In other groups it's not necessary for the regulars to point out how friendly the group is. But then, in other groups personal attacks are rare. And so when you mention Xah Lee I'm now wondering what is cause, and what is effect. I was informed that he'd done extensive cross-posting, and his own web site seems to confirm that his ISP at one time reacted to a complaint about such cross-posting. I've also seen directly that he has employed pretty foul language in characterizing Python in an article, and even without that language negative loaded characterizations without any evidence to back them up (like, for example, yours above) must be considered intentional flame bait. But did it start that way for Xah Lee? I'm not going to check the archives. It's enough, wrt. the point I'm making about some regulars of the group, that even with such evidence of active trolling at hand -- ISP reaction to cross-posting, needless foul language, unsubstantiated characterizations -- based on my experience here I think it's just as likely that it started out by Xah Lee being flamed, perhaps repeatedly, with personal attacks and by group action. Or perhaps it didn't, but at this point it would not surprise me in the slightest. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Stephen Hansen: On Tue, Feb 9, 2010 at 1:08 PM, Alf P. Steinbach al...@start.no mailto:al...@start.no wrote: [abundant snips which do not accurately represent who said what where due to my own laziness] Not sure, but perhaps it's possible to mail directly to gmane? Is there *any* problem you don't have a fatuous answer for? I thought the answer could help. You thought you cold do a bit of ad hominem attack. That's the difference between us. Well, the way I see it, you assumed you knew better than Stephen, and insisted on proposing a solution to a problem that he clearly stated he had no interest in. You're going into motivations, that it seems to me that you're projecting, saying that any helpful suggestion mean that one thinks one knows better and implies a desire to demonstrate imagined superiority. You're trying to portray a helping hand as a negative personal characteristic of the helper. the only reason that guy tries to help you is because he wishes to show how superior he (thinks he) is. That's your style in a fair number of postings, and now here: * ad hominem attack, I am, frankly, tired of this. Please stop this overly obsessive sensitivity towards what you think are ad hominem attacks. Just drop it. Its worthless. It degrades you. Your arguments are frequently nothing more then, I define the world this way and you do not disagree so I declare your argument invalid. I'm happy that even though that may (with some low probability) be your actual opinion, it's incorrect. You've dismissed at least one of my arguments with a simple hand-waving of, That's invalid, cuz. That is not a quote of me. It is a lie. The thing is, there was no basis for 'cuz' beyond In my own head this is what I think, this is how I'm defining words That's also a lie, and it's not a quote of me. And just to be clear, as anyone can see by looking up-thread, generally, contrary to your claims, I give references for whatever that I suspect might be genuinely misunderstood. And so I've done in (nearly) every article in the original thread, especially for the terms, and still people have posted articles apparently mis-interpreting those terms in very non-sensible ways -- one gets tired of that, yes. The response of others to such arguments has been, Do you /really/ need to be so absolutely right in everything?! which is said in frustration, irritation and with deep sighing. It's true that that kind of insinuative arguments have been used in this group, yes. It goes to alleged motives and alleged history instead of the technical, that is, it is a purely personal attack. So, ironically, you're here citing one kind of hominem attack -- not exactly clever when you're arguing that such does not occur. And then begins the loud declarations of ad hominem attacks. Its not productive. It doesn't help your case or arguments. Its tired. It doesn't make your case. It doesn't make anyone but you look bad. Every time you go on about, YOU ARE AD HOMINEM'N ME!, you just make yourself look worse. Yeah. People can be snarky in a community. Maybe... MAYBE... Steve Holden is periodically a little snarky at you. It is not without reason. And your declarations of his ad hominem attacks against you comes off as nothing but base /whining/. Just drop it. Its boring. Also... I'm not quite sure, given that, what the point of the advice was. There are many people who read just the Usenet group, e.g. via Google groups. When you say you don't understand the point of the advice, you're saying that * those people don't matter, and that * it doesn't matter whether they can read Stephen Hansen's articles. That's * slighting Stephen Hansen, and * showing off an extreme ego-centric view of the world, Please do NOT presume to take up my defense on ANY level. I can handle myself, thank you. I do offer unsolicited help now and then, as I gave you and for which Steve Holden decided that a bit of personal attack would be suitable. But my help was just as much in order to help others (who can't read your non-propagated articles) as in order to help you personally. That's the spirit of Usenet in many other groups. One just helps out, and often the reaction is a thank you instead of an ad hominem attack (as with Steve Holden) or, as in your case, faked quotes and general lies, which is border-line ad hominem. Anyway, please stop post faked quotes and general lies, as you do above. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, Feb 10, 2010 at 12:13 AM, Alf P. Steinbach al...@start.no wrote: You've dismissed at least one of my arguments with a simple hand-waving of, That's invalid, cuz. That is not a quote of me. It is a lie. The thing is, there was no basis for 'cuz' beyond In my own head this is what I think, this is how I'm defining words That's also a lie, and it's not a quote of me. On Wed, Feb 10, 2010 at 12:13 AM, Alf P. Steinbach al...@start.no wrote: Anyway, please stop post faked quotes and general lies, as you do above. Wow. If that's your argument, I question your sanity. None of the quotes were faked. None of the quotes were lies. If a message were intended as an actual quotation of another's words, I'd include actual citation. That a message is included in quotation-characters does not make it an actual citation. They are, quite obviously IMHO, paraphrased references to how I evaluate your arguments. The word cuz alone seems to make that very, very, very, very, very, very obvious. Get over yourself. Seriously. Quote marks don't make a quotation. If and when I choose to quote you, I will quote you. You will see a line saying, as you see above, On date, Alf etc wrote: I can handle myself, thank you. I do offer unsolicited help now and then, as I gave you and for which Steve Holden decided that a bit of personal attack would be suitable. But my help was just as much in order to help others (who can't read your non-propagated articles) as in order to help you personally. That's the spirit of Usenet in many other groups. One just helps out, and often the reaction is a thank you instead of an ad hominem attack (as with Steve Holden) or, as in your case, faked quotes and general lies, which is border-line ad hominem. I reject the assistance of you-- or anyone else-- to make my voice heard. You do not speak for me. You will not speak for me. I speak for myself, thank you. Do not presume to subjugate my voice by defending it for your purposes. Anyway, please stop post faked quotes and general lies, as you do above. I didn't. You're nuts if you think I did. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, Feb 10, 2010 at 12:13 AM, Alf P. Steinbach al...@start.no wrote: I do offer unsolicited help now and then, as I gave you and for which Steve Holden decided that a bit of personal attack would be suitable. Really, I do have to say. It's one thing to say, Aren't you being rude? (please note, this is not an actual quotation of any actual person, and I feel it is required I make this disclaimer since you have shown you are unable to differentiate a statement paraphrased in quotation marks from an actual quotation and citation of another's words) It's another thing entirely to decide on your own to be my champion and choose to speak for me in my defense. The former is someone offering unsolicited help; the latter I find more then a little insulting. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach al...@start.no wrote: In CPython objects once created remain in the same memory location (and their id is their address). Compare that to IronPython where the objects themselves can move around in memory so they have no fixed address. Try comparing the IronPython implementation to C pointers and you'll cause a lot of confusion. e.g. someone might think the id() value is in some way related to an address. Did you /read/ what you quoted? Ruby implements integers without using any pointers at all: there's nothing in the Python specification which prevents a Python implementation doing the same for small integers, in fact I believe it has been tried but wasn't found to improve performance. All theree of your points about Python are wrong; I don't know about the Ruby point. Would you care to expand upon your claim that my three points about Python are wrong? Are you saying that CPyhton objects move around, or that IronPython objects are fixed to a single memory location or that their id is related to their address? Clue here: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3082 Type help, copyright, credits or license for more information. x = 42 id(x) 43 y = 43 id(y) 44 z = whatever id(z) 45 -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, 10 Feb 2010 09:13:22 +0100, Alf P. Steinbach wrote: You've dismissed at least one of my arguments with a simple hand-waving of, That's invalid, cuz. That is not a quote of me. It is a lie. 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 a paraphrase, it's not a *lie* -- it should be read as Stephen's *opinion* of your actions, not a direct quote. Stephen might, or might not, be *mistaken*, but it's unlikely he's actively lying. Arguing pedantically that you didn't write those exact words won't win you any friends or supporters. You can choose to defend yourself against a gross misrepresentation of what you actually said; or you can accept that it captures the spirit (but not the letter) of your words; or you can choose a middle position, and accept that even if it is not a 100% accurate representation of your statements, perhaps it is 90% accurate, or 10%, or 50%. The exact amount doesn't really matter, and will be subjective, and frankly I don't care. But whatever degree you choose to accept, it is obvious that a number of people are not just being annoyed by your behaviour, but they are annoyed enough to publicly chastise you for it. That includes Steve Holden, who is usually far more even-tempered than (e.g.) me. Without necessarily suggesting that you are 100% to blame for the antagonism, its unlikely that so many disparate individuals are all 100% mistaken. As you say, the public record is there for anyone who wishes to read the history. Believe me Alf, the fact that people are taking the time to try to argue with you instead of just kill-filing you is a compliment. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, Feb 10, 2010 at 6:16 AM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: 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.) Hm. I hadn't considered that others may interpret my words in the context of other cultural punctuation rules; it seemed obvious to me that the phrases Alf declared a lie were an opinion, and indeed as Steven points out, my interpretation and paraphrasing of the original arguments. Apologies if you considered it a direct quote and thought I was attempting to assert you actually said what was in quote marks. The comments were simply my interpretation (accurate or inaccurate as that may be, it is my interpretation) of your remarks, and not a quotation of your remarks to be attributed to you. --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Duncan Booth: Alf P. Steinbach al...@start.no wrote: In CPython objects once created remain in the same memory location (and their id is their address). Compare that to IronPython where the objects themselves can move around in memory so they have no fixed address. Try comparing the IronPython implementation to C pointers and you'll cause a lot of confusion. e.g. someone might think the id() value is in some way related to an address. Did you /read/ what you quoted? Ruby implements integers without using any pointers at all: there's nothing in the Python specification which prevents a Python implementation doing the same for small integers, in fact I believe it has been tried but wasn't found to improve performance. All theree of your points about Python are wrong; I don't know about the Ruby point. Would you care to expand upon your claim that my three points about Python are wrong? Sure. I already did in the article you're replying to, immediately following what you quote above. You snipped that which you're asking for, so I requote: quote First, the current Python language specification formally prevents the optimization you mention, because there's no support for binding to do anything but direct binding leaving object identities unchanged. But in practice that's no big deal though: I can't imagine any code relying on identities of completely immutable objects. Second, even the variant that was tried improved performance. But it would reportedly have wreaked havoc with imperfect C code. Third, the optimization doesn't do away with pointers. If it did then it would transform the language completely. The user's view is still one where names denote pointers. /quote Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Are you saying that CPyhton objects move around, or that IronPython objects are fixed to a single memory location or that their id is related to their address? No, I can't see how you can deduce any such connection from I wrote. Whether objects move around depends on what exactly you mean by move around, and given that, it may then depend on the Python implementation. However, from the Python point of view every object has a fixed unique id, available via id(). Clue here: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3082 Type help, copyright, credits or license for more information. x = 42 id(x) 43 y = 43 id(y) 44 z = whatever id(z) 45 I'm guessing wildly that you're trying to illustrate id's that don't correspond to memory addresses? If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Wed, 10 Feb 2010 09:13:22 +0100, Alf P. Steinbach wrote: You've dismissed at least one of my arguments with a simple hand-waving of, That's invalid, cuz. That is not a quote of me. It is a lie. 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. I'm aware that Stephen Hansen maintains that, but I'm not replying to his ramblings about insanity and so on (perhaps he is a child, but I'm not replying to that kind of stuff). Anyway, in the original article he refererred to part of the quoted text, quoting that in turn as an example of how allegedly patronising (or whatever) I'd been to him. Re-quoting a part *does not make sense* for paraphrasing. And anyway, he wrote a piece where quotes seemed to signify quoting, drawing conclusions from the quoted text. It's just plain lying. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Steven D'Aprano wrote: Believe me Alf, the fact that people are taking the time to try to argue with you instead of just kill-filing you is a compliment. It's a compliment I am not paying, although I am grateful to those who are attempting to teach him. At the rate it's going, though, I don't see myself buying any book he produces. Besides the arrogant attitude, he is wrong on so many things about Python it is truly stunning. He seems to have confidence born of ignorance... a scary sight to see. In the spirit of being helpful and not just being a jerk myself: Alf, Using smileys after declaring somebody is mistaken/wrong/etc makes you look bad. Not attempting to learn the language makes you look like an arrogant idiot (case in point: passing-by-object). Accusing anyone and everyone that criticizes you of making ad hominem (sp?) attacks makes you look like a whiner. After all is said and done - if you had a truly good grasp of Python, I might buy your book even if you still had -- ummm -- a less than winning presence on the mailing list; but right now your understanding is not worth paying for. Hoping-this-helps-but-not-really-expecting-it-to-ly yours, ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Duncan Booth: Alf P. Steinbach al...@start.no wrote: In CPython objects once created remain in the same memory location (and their id is their address). Compare that to IronPython where the objects themselves can move around in memory so they have no fixed address. Try comparing the IronPython implementation to C pointers and you'll cause a lot of confusion. e.g. someone might think the id() value is in some way related to an address. Did you /read/ what you quoted? Ruby implements integers without using any pointers at all: there's nothing in the Python specification which prevents a Python implementation doing the same for small integers, in fact I believe it has been tried but wasn't found to improve performance. All theree of your points about Python are wrong; I don't know about the Ruby point. Would you care to expand upon your claim that my three points about Python are wrong? Sure. I already did in the article you're replying to, immediately following what you quote above. You snipped that which you're asking for, so I requote: quote First, the current Python language specification formally prevents the optimization you mention, because there's no support for binding to do anything but direct binding leaving object identities unchanged. But in practice that's no big deal though: I can't imagine any code relying on identities of completely immutable objects. Second, even the variant that was tried improved performance. But it would reportedly have wreaked havoc with imperfect C code. Third, the optimization doesn't do away with pointers. If it did then it would transform the language completely. The user's view is still one where names denote pointers. /quote Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Are you saying that CPyhton objects move around, or that IronPython objects are fixed to a single memory location or that their id is related to their address? No, I can't see how you can deduce any such connection from I wrote. Whether objects move around depends on what exactly you mean by move around, and given that, it may then depend on the Python implementation. However, from the Python point of view every object has a fixed unique id, available via id(). Clue here: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.3082 Type help, copyright, credits or license for more information. x = 42 id(x) 43 y = 43 id(y) 44 z = whatever id(z) 45 I'm guessing wildly that you're trying to illustrate id's that don't correspond to memory addresses? If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. You go too far here. What you are referring to in your bizarrely constructed definition above as a pointer does not allow you to access the value that is pointed to. So I fail to see why you feel its its introduction is necessary. Whether in CPython, Jython or IronPython the value returned by calling id(x) (whether x is a literal, a simple name or a more complex expression) is absolutely no use as an accessor: it does not give you access to the referenced value. If you disagree, please write (in any implementation you like: it need not even be portable, though I can't imagine why ti wouldn't be) a Python function which takes an id() value as its argument and returns the value for which the id() value was provided. So in your world it's unnecessary for pointers to point to anything (or references to refer to something)? For someone who cheerfully admits to being wrong from time to time (an admirable characteristic) you are certainly difficult to convince on this point. One wonders what further hand-waving will follow. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Python doesn't have copyable reference values in the Python level. It has objects. It seems to me that your argument is based on the premises: (1) that the value of a variable is not what 99.99% of people would describe as the value, but is some hidden, implementation dependent pointer instead; (2) that pointer doesn't necessarily mean what 99% of people who learned C or Pascal understand by pointer; (3) that mangling both common English and programmers' expectations in that fashion is somehow more accurate and more useful than using the 35 year old term call by object (or call by object reference); (4) and, presumably because of some deeply-held belief that the only parameter passing strategies that we're allowed to talk about are call by value and call by reference, no matter how much violence we do to the concept of both value and pointer, Python and Java must be call-by- value since they clearly aren't call-by-reference. Of these, the only one that I consider value is that Python and Java are not call-y-reference. Otherwise, I reject all these premises, and consequently none of your arguments make the slightest sense to me. You keep talking about Python operating on pointers. I've never used a single pointer in 10+ years of Python coding, no matter how many times you tell me I have. What the implementation of the Python virtual machine does is not what I do high-level Python code, and the implementation is not the language. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: [snip] Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. [snip] If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. You go too far here. What you are referring to in your bizarrely constructed definition above No, it's not bizarre, it's the standard general language independent definition. And since I'm referring to an external definition (Java) it's not mine, either. :-) as a pointer does not allow you to access the value that is pointed to. So I fail to see why you feel its its introduction is necessary. Python provides a number of ways to access the object pointed to. Attribute access, indexing, and operators access the objects pointed to. For example, x = s[0] accesses the object that s points (refers) to. While 'is', 'id' and assignment operate on the pointers (references) themselves. So there's one set of language features that operate on pointers, and one set of language features that operate on the pointed to objects. This is so also in Java and C#. For example. Whether in CPython, Jython or IronPython the value returned by calling id(x) (whether x is a literal, a simple name or a more complex expression) is absolutely no use as an accessor: it does not give you access to the referenced value. Yes, the id does not give you access to the referenced object. If you disagree, please write (in any implementation you like: it need not even be portable, though I can't imagine why ti wouldn't be) a Python function which takes an id() value as its argument and returns the value for which the id() value was provided. No, I don't disagree with that. It would be excessively inefficient to do, involving enumeration of all objects. So in your world it's unnecessary for pointers to point to anything (or references to refer to something)? For someone who cheerfully admits to being wrong from time to time (an admirable characteristic) you are certainly difficult to convince on this point. One wonders what further hand-waving will follow. He he, further handwaiving: you're good at unsubstantiated allegations. I generally strive to provide concrete examples, and you know it. Anywyay, treating the first sentence as a genuine question: in the most likely interpretation it seems that you're conflating id's with pointers. An id() value uniquely represents a pointer (i.e., the identity of the object pointed to). It is not itself a pointer since it lack any pointer semantics. 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. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Ethan Furman: Steven D'Aprano wrote: Believe me Alf, the fact that people are taking the time to try to argue with you instead of just kill-filing you is a compliment. It's a compliment I am not paying, although I am grateful to those who are attempting to teach him. At the rate it's going, though, I don't see myself buying any book he produces. Besides the arrogant attitude, he is wrong on so many things about Python it is truly stunning. That's bullshit. I am probably wrong about many Python things, for this is so no matter the language and the practictioner, but not any that you know about. He seems to have confidence born of ignorance... a scary sight to see. In the spirit of being helpful and not just being a jerk myself: Alf, Using smileys after declaring somebody is mistaken/wrong/etc makes you look bad. Not attempting to learn the language makes you look like an arrogant idiot (case in point: passing-by-object). Accusing anyone and everyone that criticizes you of making ad hominem (sp?) attacks makes you look like a whiner. After all is said and done - if you had a truly good grasp of Python, I might buy your book even if you still had -- ummm -- a less than winning presence on the mailing list; but right now your understanding is not worth paying for. Hoping-this-helps-but-not-really-expecting-it-to-ly yours, It's yet another ad hominem attack, which means that you're painfully aware of supporting an untenable technical position, or supporting a clique of people. It also reflects rather badly on you. Cheers hth., - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On 2/10/2010 1:38 PM, Ethan Furman wrote: After all is said and done - if you had a truly good grasp of Python, I might buy your book even if you still had -- ummm -- a less than winning presence on the mailing list; but right now your understanding is not worth paying for. Alf, here's my suggestion on how to respond to people's criticisms of your technical prowess: come up with the best ever description of Python's variable-assignment and argument-passing schemes, and place the description in your manuscript [1]. Section 2.4, Naming things, currently does not address the issues discussed in this thread (pass by XXX, etc.). HTH, John [1] http://mail.python.org/pipermail/python-list/2009-December/1229932.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Python doesn't have copyable reference values in the Python level. It has objects. Given s = [1] t = s # Copies reference. t[0] = 2 # Changes referenced object via copied reference. print( s )# Checks the object via the original reference. your argument that the copied reference does not exist, is just silly. And you know it. It seems to me that your argument is based on the premises: (1) that the value of a variable is not what 99.99% of people would describe as the value, but is some hidden, implementation dependent pointer instead; No. The Python language spec defines what value of an object means. And people use value with many different meanings, using Common Sense to arbitrate. It would be senseless to try to pin down a single meaning of the word value. You're arguing against a position unrelated to mine. (2) that pointer doesn't necessarily mean what 99% of people who learned C or Pascal understand by pointer; No. But although this is just a terminological issue, it's worth discussing. I refuse to believe that 99% of C and Pascal programmers believe that pointer only refers to the pointer implementation in their language of choice. In my first article in this thread I specifically referred to the Java language specification, which says, first sentence in §4.3.1 in the 3.0 spec, that The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object. which is relevant to Python because Java has the same semantics, although Java NullPointerException is called unbound in Python (but this is again just terminology, not semantics). I.e., the general pointer term /can/ be used, and is used, for reference values. Only a willingness to misinterpret can cause confusion, at least when the terminology is defined, as I've done all the time. Secondly I referred (actually that was in response to you) to a Stanford University introduction to pointers, comparing four languages including Java. I didn't refer you to Wikipedia because that article seems to lack mention of reference based languages and does include a reference to an article that I wrote about pointers in C++ (now off-net), and given the noise level here it would therefore probably not help. (3) that mangling both common English and programmers' expectations in that fashion is somehow more accurate and more useful than using the 35 year old term call by object (or call by object reference); No, I haven't stated any opposition to using that term; the archives show the opposite. So for the second time here you're arguing against a silly position that I do not hold. (4) and, presumably because of some deeply-held belief that the only parameter passing strategies that we're allowed to talk about are call by value and call by reference, no matter how much violence we do to the concept of both value and pointer, Python and Java must be call-by- value since they clearly aren't call-by-reference. Well that's the third time here that you're arguing against a silly position that I do not hold. Of these, the only one that I consider value is that Python and Java are not call-y-reference. Otherwise, I reject all these premises, Good rejection as far as 1, 3 and 4 are concerned. Regarding the term pointer, your point 2, I strongly encourage you to seek out the sources I've referenced and quoted. For without a common language it's difficult to communicate, and if Python programmers should continue to not understand common terms then that would just further flame wars such as this thread has escalated to. Please seek out sources. Don't just take my word, instead, read e.g. what I've quoted, try out the example I've given, and so on: be critical (to your own assumptions also!). and consequently none of your arguments make the slightest sense to me. Well, you'd first have to examine at least one of my arguments. In this article you haven't, instead attacking a number of positions that I haven't advocated and do not hold, except for your silly denial of existence of references at the top. But that's just silly -- consider the concrete example given. You keep talking about Python operating on pointers. I've never used a single pointer in 10+ years of Python coding, no matter how many times you tell me I have. What the implementation of the Python virtual machine does is not what I do high-level Python code, and the implementation is not the language. Here again you're conflating things and engage in a kind of denial coupled with a correct argument. It's hard to argue against such confusion. Instead I've tried above to address your only relevant point,
Re: Modifying Class Object
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. 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. 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. 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* 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
Re: Modifying Class Object
Alf P. Steinbach wrote: * Ethan Furman: Steven D'Aprano wrote: Believe me Alf, the fact that people are taking the time to try to argue with you instead of just kill-filing you is a compliment. It's a compliment I am not paying, although I am grateful to those who are attempting to teach him. At the rate it's going, though, I don't see myself buying any book he produces. Besides the arrogant attitude, he is wrong on so many things about Python it is truly stunning. That's bullshit. I am probably wrong about many Python things, for this is so no matter the language and the practictioner, but not any that you know about. So your accomplishments include mind-reading now, and you understand everything that Stephen knows and does not know about? That's a startling and, I suggest, untenable claim. He seems to have confidence born of ignorance... a scary sight to see. In the spirit of being helpful and not just being a jerk myself: Alf, Using smileys after declaring somebody is mistaken/wrong/etc makes you look bad. Not attempting to learn the language makes you look like an arrogant idiot (case in point: passing-by-object). Accusing anyone and everyone that criticizes you of making ad hominem (sp?) attacks makes you look like a whiner. After all is said and done - if you had a truly good grasp of Python, I might buy your book even if you still had -- ummm -- a less than winning presence on the mailing list; but right now your understanding is not worth paying for. Hoping-this-helps-but-not-really-expecting-it-to-ly yours, It's yet another ad hominem attack, which means that you're painfully aware of supporting an untenable technical position, or supporting a clique of people. So now the whole thing boils down to Alf against the world? The reminds me of the story about the woman who went to see her son qualify from his basic army training. When asked what she thought of the parade she said it was very nice, but that everyone but our Alf was out of step. I am unsure at this stage what it would take to convince you that you are not only wrong about several important aspects of Python but also wrong-headed. Whenever anyone points out any aspect of your behavior which is unacceptable or ignorant you trot out this accusation that people are making ad hominem attacks as though commenting on aspects of your personality is an attempt to undermine your arguments. It isn't. The two are orthogonal. Your arguments are wrong *and* you are behaving like a pratt. A change in either one of these aspects would improve matters, but each seems as unlikely as the other. It also reflects rather badly on you. Sigh. We're all out of step again, obviously. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: So now the whole thing boils down to Alf against the world? The reminds me of the story about the woman who went to see her son qualify from his basic army training. When asked what she thought of the parade she said it was very nice, but that everyone but our Alf was out of step. Considering your frequent ad hominem attacks (and this is yet one more), you seem to think that social coercion works well for establishing engineering solutions or scientific truth. That's a misconception. Social matters and matters of engineering or science are different things. I am unsure at this stage what it would take to convince you that you are not only wrong about several important aspects of Python but also wrong-headed. You might start by starting a thread about one such thing; I'll correct you if you're wrong about something I know, or if you demonstrate that I'm wrong about something, then I'll be happy to learn something, as always. It would be a nice change from your extreme focus on my person, if you could manage to discuss something technical. Whenever anyone points out any aspect of your behavior which is unacceptable or ignorant you trot out this accusation that people are making ad hominem attacks as though commenting on aspects of your personality is an attempt to undermine your arguments. That's an ad hominem attack, albeit a pretty silly one. Your behavior, with ad hominem, coercion, insinuations, misrepresentations and so forth the basic ingredients, is completely unacceptable to me, by the way. It's like a bully in the schoolyard. It isn't. The two are orthogonal. Your arguments are wrong *and* you are behaving like a pratt. A change in either one of these aspects would improve matters, but each seems as unlikely as the other. It also reflects rather badly on you. Sigh. We're all out of step again, obviously. If you had any argument that held regarding the technical, then I think you (and I mean the singular you) would have tried it by now. But instead, you engage in this bullying behavior. Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: [snip] Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. [snip] If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. You go too far here. What you are referring to in your bizarrely constructed definition above No, it's not bizarre, it's the standard general language independent definition. *The* standard general language independent definition? As defined where? The id() value doesn't correspond to the pointer value, it corresponds to the object. Why you see the need for this indirection remains a mystery. And since I'm referring to an external definition (Java) it's not mine, either. :-) as a pointer does not allow you to access the value that is pointed to. So I fail to see why you feel its its introduction is necessary. Python provides a number of ways to access the object pointed to. Attribute access, indexing, and operators access the objects pointed to. No, they access the objects. In the IronPython implementation, for example, it has already been shown quite clearly that the id value is simply an attribute of the object, whose values are incremented by one for each new object. For example, x = s[0] accesses the object that s points (refers) to. It accesses (the first element of) the object bound to the name s. While 'is', 'id' and assignment operate on the pointers (references) themselves. The 'is' operator is a simple test for equality of ids of the objects resulting from the evaluation of two expressions. The expressions can be literals, simple names, or any other valid Python expression. They are *not* pointers, or references. id() simply returns a unique value identifying a particular object. In CPython, where objects do not migrate in memory once created, the memory address of the object is used. In IronPython each object is assigned an id when it is created, and that value is stored as an attribute. So there's one set of language features that operate on pointers, and one set of language features that operate on the pointed to objects. This is so also in Java and C#. For example. Whether in CPython, Jython or IronPython the value returned by calling id(x) (whether x is a literal, a simple name or a more complex expression) is absolutely no use as an accessor: it does not give you access to the referenced value. Yes, the id does not give you access to the referenced object. Well at least we have found one aspect of Python we agree on. If you disagree, please write (in any implementation you like: it need not even be portable, though I can't imagine why ti wouldn't be) a Python function which takes an id() value as its argument and returns the value for which the id() value was provided. No, I don't disagree with that. Good. It would be excessively inefficient to do, involving enumeration of all objects. So in your world it's unnecessary for pointers to point to anything (or references to refer to something)? For someone who cheerfully admits to being wrong from time to time (an admirable characteristic) you are certainly difficult to convince on this point. One wonders what further hand-waving will follow. He he, further handwaiving: you're good at unsubstantiated allegations. I am simply pointing out that to make your point you are relying on abstractions which increasingly diverge from the reality of the Python language. I don't think it's unreasonable to describe that as hand-waving. You apparently do. I generally strive to provide concrete examples, and you know it. Again with the mind-reading: you appear to have convinced yourself that you are an authority on what I know. Anywyay, treating the first sentence as a genuine question: in the most likely interpretation it seems that you're conflating id's with pointers. An id() value uniquely represents a pointer (i.e., the identity of the object pointed to). It is not itself a pointer since it lack any pointer semantics. No, it doesn't uniquely represent a pointer, it uniquely represents an *object*. 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
Re: Modifying Class Object
On Wed, Feb 10, 2010 at 7:49 PM, Steve Holden st...@holdenweb.com wrote: *The* standard general language independent definition? As defined where? Wait, what happened here? This thread started a couple days ago; you pointed out its futility, and even knowing better, I jumped in the deep end. When I realized the futility, you rightly I-told-you-so'd me. You didn't have to pick up my slack ;) On Mon, Feb 8, 2010 at 6:42 PM, Steve Holden st...@holdenweb.com wrote: Of course this won't make the slightest difference. 'When I use a word,' said Humpty ... --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach wrote: * Steve Holden: So now the whole thing boils down to Alf against the world? The reminds me of the story about the woman who went to see her son qualify from his basic army training. When asked what she thought of the parade she said it was very nice, but that everyone but our Alf was out of step. Considering your frequent ad hominem attacks (and this is yet one more), you seem to think that social coercion works well for establishing engineering solutions or scientific truth. That's a misconception. So now I understand neither engineering nor science? I find that assertion offensive, though unsurprising. Social matters and matters of engineering or science are different things. I am hardly ignorant of that, as you should know from my many past writings on both aspects of Python usage. You are attempting to teach your grandmother to suck eggs. I am unsure at this stage what it would take to convince you that you are not only wrong about several important aspects of Python but also wrong-headed. You might start by starting a thread about one such thing; I'll correct you if you're wrong about something I know, or if you demonstrate that I'm wrong about something, then I'll be happy to learn something, as always. It would be a nice change from your extreme focus on my person, if you could manage to discuss something technical. See below. Whenever anyone points out any aspect of your behavior which is unacceptable or ignorant you trot out this accusation that people are making ad hominem attacks as though commenting on aspects of your personality is an attempt to undermine your arguments. That's an ad hominem attack, albeit a pretty silly one. [facepalm] Your behavior, with ad hominem, coercion, insinuations, misrepresentations and so forth the basic ingredients, is completely unacceptable to me, by the way. It's like a bully in the schoolyard. I am attempting to persuade, not to coerce. It isn't. The two are orthogonal. Your arguments are wrong *and* you are behaving like a pratt. A change in either one of these aspects would improve matters, but each seems as unlikely as the other. It also reflects rather badly on you. Sigh. We're all out of step again, obviously. If you had any argument that held regarding the technical, then I think you (and I mean the singular you) would have tried it by now. But instead, you engage in this bullying behavior. My (technical) views on your insistence that Python's semantics require the use of pointers to explain them is ongoing elsewhere, and remains open for you to refute. In this particular part of the thread I am attempting, unsuccessfully, to convince you that a change in *your* behavior would lead to less hostility directed towards the way you present your ideas. You apparently feel it is quite acceptable to tell people to learn to read, and calling their assertions bullshit, but when we try to point out aspects of your behavior that are either undesirable or unacceptable we are indulging in ad hominem attacks. In your terms, your accusing me of bullying behavior is an ad hominem attack on me, so I won't bother to respond further. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Stephen Hansen wrote: On Wed, Feb 10, 2010 at 7:49 PM, Steve Holden st...@holdenweb.com mailto:st...@holdenweb.com wrote: *The* standard general language independent definition? As defined where? Wait, what happened here? This thread started a couple days ago; you pointed out its futility, and even knowing better, I jumped in the deep end. When I realized the futility, you rightly I-told-you-so'd me. You didn't have to pick up my slack ;) On Mon, Feb 8, 2010 at 6:42 PM, Steve Holden st...@holdenweb.com mailto:st...@holdenweb.com wrote: Of course this won't make the slightest difference. 'When I use a word,' said Humpty ... Yes, but someone on the Internet is wrong, dammit, I can't go to bed yet. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Steve Holden: Alf P. Steinbach wrote: [snip] Since in the quoting above no reference to definition of pointer remains: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. [snip] If so, then that's correct: a Python (or Java, or whatever language) pointer is not necessarily directly a memory address, and furthermore id is not guaranteed to reproduce the bits of a pointer value -- which might not even make sense. All that id does is to produce a value that uniquely identifies the object pointed to, i.e. it corresponds to the pointer value, and although in CPython that's simply the bits of a C pointer typed as integer, in IronPython it's not. You go too far here. What you are referring to in your bizarrely constructed definition above No, it's not bizarre, it's the standard general language independent definition. *The* standard general language independent definition? Yes. As defined where? For example, as I used as reference in my first posting, the Java language spec. But it has nothing specifically to do with Java. It is a basic concept in computer science, that (most) CS students learn in their *first year*. E.g. quote src=http://cslibrary.stanford.edu/106/; A pointer stores a reference to something. Unfortunately there is no fixed term for the thing that the pointer points to, and across different computer languages there is a wide variety of things that pointers point to. We use the term pointee for the thing that the pointer points to, and we stick to the basic properties of the pointer/pointee relationship which are true in all languages. The term reference means pretty much the same thing as pointer -- reference implies a more high-level discussion, while pointer implies the traditional compiled language implementation of pointers as addresses. For the basic pointer/pointee rules covered here, the terms are effectively equivalent. /quote Note that that discussion at Stanford University has several Java examples + a FAQ about the application of the term pointer to Java (plus of course that that's specified by the language spec), so implies ... pointers as addresses is not smart to get too focused on. Some common sense is required. As mentioned, it is for first-year students. But anyway, this is just terminology; if you don't like the term, then invent or suggest one that you're able to grok or think others will more likely grok. The id() value doesn't correspond to the pointer value, it corresponds to the object. Why you see the need for this indirection remains a mystery. The language specifies pointer semantics, that's all. You can copy and replace references. So, they quack like pointers, waddle like pointers and look like pointers: = pointers. And since I'm referring to an external definition (Java) it's not mine, either. :-) as a pointer does not allow you to access the value that is pointed to. So I fail to see why you feel its its introduction is necessary. Python provides a number of ways to access the object pointed to. Attribute access, indexing, and operators access the objects pointed to. No, they access the objects. What's the difference between access the objects and access the objects? I'm not genuinely interested in how you came up with this amazing rebuttal, it was a rhetorical question only. But I note that the only difference seems to be that you don't want the objects to be referenced (pointed to) by anything, removing that bit of text, which would make it a bit problematic to apply /any/ operation... In the IronPython implementation, for example, it has already been shown quite clearly that the id value is simply an attribute of the object, whose values are incremented by one for each new object. Please demonstrate how that is relevant to whatever you're arguing. For example, x = s[0] accesses the object that s points (refers) to. It accesses (the first element of) the object bound to the name s. Yes. While 'is', 'id' and assignment operate on the pointers (references) themselves. The 'is' operator is a simple test for equality of ids of the objects resulting from the evaluation of two expressions. The expressions can be literals, simple names, or any other valid Python expression. Yes. They are *not* pointers, or references. Simple demonstration that they're references (have reference semantics): s = [A] t = s # Copies the reference. t[0] = B# Changes the referenced object via the reference copy. print( s )# Inspects object (now changed) via original reference. It's pretty hard to argue seriously against this without committing a number of fallacies. Denial is of course easy, and you've done that, but it's at best just childish. id() simply returns a unique value identifying a particular object. In
RE: Modifying Class Object
Steve wrote:
id() simply returns a unique value identifying a particular object. In
CPython, where objects do not migrate in memory once created, the
memory
address of the object is used. In IronPython each object is assigned an
id when it is created, and that value is stored as an attribute.
Just a point of clarification: In IronPython ids are lazily assigned upon
a call to the id(). They're actually fairly expensive to create because
the ids need to be maintained by a dictionary which uses weak references.
If you disagree, please write (in any implementation you like: it need
not even be portable, though I can't imagine why ti wouldn't be) a
Python function which takes an id() value as its argument and
returns the value for which the id() value was provided.
Just for fun this works in IronPython 2.6:
import clr
clr.AddReference('Microsoft.Dynamic')
from Microsoft.Scripting.Runtime import IdDispenser
x = object()
id(x)
43
IdDispenser.GetObject(43)
object object at 0x002B
IdDispenser.GetObject(43) is x
True
Please, please, no one ever use this code!
I do generally agree with the sentiment that id is object identity and in
way related to pointers though.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steve Holden: Alf P. Steinbach wrote: * Steve Holden: So now the whole thing boils down to Alf against the world? The reminds me of the story about the woman who went to see her son qualify from his basic army training. When asked what she thought of the parade she said it was very nice, but that everyone but our Alf was out of step. Considering your frequent ad hominem attacks (and this is yet one more), you seem to think that social coercion works well for establishing engineering solutions or scientific truth. That's a misconception. So now I understand neither engineering nor science? I find that assertion offensive, though unsurprising. Social matters and matters of engineering or science are different things. I am hardly ignorant of that, as you should know from my many past writings on both aspects of Python usage. You are attempting to teach your grandmother to suck eggs. I am unsure at this stage what it would take to convince you that you are not only wrong about several important aspects of Python but also wrong-headed. You might start by starting a thread about one such thing; I'll correct you if you're wrong about something I know, or if you demonstrate that I'm wrong about something, then I'll be happy to learn something, as always. It would be a nice change from your extreme focus on my person, if you could manage to discuss something technical. See below. Whenever anyone points out any aspect of your behavior which is unacceptable or ignorant you trot out this accusation that people are making ad hominem attacks as though commenting on aspects of your personality is an attempt to undermine your arguments. That's an ad hominem attack, albeit a pretty silly one. [facepalm] Your behavior, with ad hominem, coercion, insinuations, misrepresentations and so forth the basic ingredients, is completely unacceptable to me, by the way. It's like a bully in the schoolyard. I am attempting to persuade, not to coerce. It isn't. The two are orthogonal. Your arguments are wrong *and* you are behaving like a pratt. A change in either one of these aspects would improve matters, but each seems as unlikely as the other. It also reflects rather badly on you. Sigh. We're all out of step again, obviously. If you had any argument that held regarding the technical, then I think you (and I mean the singular you) would have tried it by now. But instead, you engage in this bullying behavior. My (technical) views on your insistence that Python's semantics require the use of pointers to explain them is ongoing elsewhere, and remains open for you to refute. In this particular part of the thread I am attempting, unsuccessfully, to convince you that a change in *your* behavior would lead to less hostility directed towards the way you present your ideas. You apparently feel it is quite acceptable to tell people to learn to read, I have not used that expression. However I have suggest and emphasized that it might help to *read* whatever one quotes, when the quoted material (such as one paragraph) has not been read. Telling someone to learn to read is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Telling a person to read something that's obviously not been read is quite another matter. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. and calling their assertions bullshit, Yes, in this group, but only for personal attacks. Such as yours. I think I've shown extreme restraint in the face of bullying from you and some followers, and calling the insinuations bullshit is quite mild. but when we try to point out aspects of your behavior that are either undesirable or unacceptable we are indulging in ad hominem attacks. That is an untrue and extremely misleading description of what you've been doing. In your terms, your accusing me of bullying behavior is an ad hominem attack on me, so I won't bother to respond further. You're complaining about the person you're hitting saying clearly what you did. If some truthful words about bullying can get you straight I'm for it. Even if it means getting down to your level (and yes, I did). Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Wed, 10 Feb 2010 23:56:36 +0100, Alf P. Steinbach wrote: * Steven D'Aprano: On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Python doesn't have copyable reference values in the Python level. It has objects. Given s = [1] t = s # Copies reference. t[0] = 2 # Changes referenced object via copied reference. print( s )# Checks the object via the original reference. your argument that the copied reference does not exist, is just silly. And you know it. You keep making a habit of pretending that you know what other people are thinking, accusing them of lying for having an opinion that differs from yours, and of deliberately making silly arguments that the poster (in this case, me) knows is untrue. It is an obnoxious, trolling habit. Please stop it. I don't know it is a silly argument, because I don't accept your givens. Specifically: s = [1] t = s # Binds the name t to the object bound to the name s. t[0] = 2 # Changes the object bound to the name t print(s) # Checks the object via the original name. Notice that your version describes what happens according to some implementation, below the level of the Python virtual machine. My version describes what happens at the level of high-level Python code, which is the defined semantics of the language. It makes no assumptions about the implementation, completely unlike yours which is entirely implementation- specific. My description is equally valid whether Python is being executed by the CPython virtual machine on an Intel-compatible processor, or hand-simulated with pencil and paper, or something completely different. Yours is not. I describe the high-level language, you describe one implementation. Neither view is *wrong*, per se, but one describes the semantics of the language while the other describes the implementation. The first paragraph of the Python docs about the execution model says: NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name binding operations. Each occurrence of a name in the program text refers to the binding of that name established in the innermost function block containing the use. http://docs.python.org/reference/executionmodel.html Apart from the use of the generic English term refers to (and similar), you will find *nothing* about pointers in this. That's because pointers are not a part of the high-level behaviour of Python. See also: http://docs.python.org/reference/simple_stmts.html#assignment-statements where you will also not find the word pointer used to describe any high- level Python feature, or used in relation to assignment. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
Alf P. Steinbach al...@start.no wrote: Telling someone to learn to read is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Ad hominem. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. Ad hominem. Yes, in this group, but only for personal attacks. Such as yours. Ad hominem. I think I've shown extreme restraint in the face of bullying from you and some followers, and calling the insinuations bullshit is quite mild. Ad hominem. That is an untrue and extremely misleading description of what you've been doing. Ad hominem. Even if it means getting down to your level (and yes, I did). Ad hominem. So the real lesson you're trying to impart is to do as you say and not as you do? -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano: On Wed, 10 Feb 2010 23:56:36 +0100, Alf P. Steinbach wrote: * Steven D'Aprano: On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote: pointer refers to a copyable reference value as seen from the Python level, in the same way as pointer is used by e.g. the Java language spec. Python doesn't have copyable reference values in the Python level. It has objects. Given s = [1] t = s # Copies reference. t[0] = 2 # Changes referenced object via copied reference. print( s )# Checks the object via the original reference. your argument that the copied reference does not exist, is just silly. And you know it. You keep making a habit of pretending that you know what other people are thinking, No, that is untrue, I do neither know nor pretend to know what other people are thinking. But I do know that you know some elementary things, such as understanding what the code above does. I do not by that mean that you don't also understand far more advanced things :-), just that I'm fairly ~100% sure that you do understand the code above. accusing them of lying for having an opinion that differs from yours, That is untrue. [snip] I don't know it is a silly argument, because I don't accept your givens. Specifically: s = [1] t = s # Binds the name t to the object bound to the name s. t[0] = 2 # Changes the object bound to the name t print(s) # Checks the object via the original name. Notice that your version describes what happens according to some implementation, below the level of the Python virtual machine. Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? If it doesn't, then it has no effect whatsoever. But since it does have an effect, a memory change has been effected. You describe that memory change as that t has been bound to the same object as s. By which you mean that henceforth, until the next assignment to t, t *refers* to the same object as s. That explanation in terms of refers is necessary. No beginner knows what it means that a name is bound to something means, until it's been explained. The explanation is necessarily in terms of refers to. When something A refers to something B, then by definition A is a *reference* to B. Anyway, you have changed which object t refers to, by changing memory contents so that t now refers to the same object as s. Effectively, by making t refer to the same object as s, by all measures of reference equality (which is just, do they refer to same object?) you have *copied* the s reference to t. For if you haven't, then t necessarily refers to something else. So the memory change, whatever it was, involved an effective copying of a reference, in memory. And that copying of a reference, in memory, implies a copyable reference. Going the other way, copying of references very directly implies binding. No need for the long logic chain above. So copying of references is in my view much more powerful as a model of what goes on, yielding immediate conclusions, avoiding special case rules, and being very suitable for visualization. Not the least, it's more powerful because in order to explain bind you need refer and reference, so the bind view involves more, violating Occam's. But given the explanation in terms of refer and reference you do not need bind, so it's less, it's simpler -- and it's easier to visualize. --- Anyway, there is more practical way to look at it. Say that you're going to implement a linked list. The functionality required for that is exactly that of general pointers. But a linked list can be implemented in Python, using names (attributes) as pointers. And since that works, without having to do anything extra in order to implement pointers in terms of names, but just using those names directly, those names necessarily have the functionality of general pointers. My version describes what happens at the level of high-level Python code, which is the defined semantics of the language. It makes no assumptions about the implementation, completely unlike yours which is entirely implementation- specific. My description is equally valid whether Python is being executed by the CPython virtual machine on an Intel-compatible processor, or hand-simulated with pencil and paper, or something completely different. Yours is not. I describe the high-level language, you describe one implementation. Neither view is *wrong*, per se, but one describes the semantics of the language while the other describes the implementation. The first paragraph of the Python docs about the execution model says: NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name binding operations. Each occurrence of a name in the program text refers to the binding of that name established in the innermost function block containing the use.
Re: Modifying Class Object
* alex23: Alf P. Steinbach al...@start.no wrote: Telling someone to learn to read is a Steve Holden'sk way to imply that the person is an ignoramus who hasn't bothered to learn to read. Ad hominem. So, you are misrepresenting -- again -- and in a quite revealing way, sorry. Ad hominem. Yes, in this group, but only for personal attacks. Such as yours. Ad hominem. I think I've shown extreme restraint in the face of bullying from you and some followers, and calling the insinuations bullshit is quite mild. Ad hominem. That is an untrue and extremely misleading description of what you've been doing. Ad hominem. Even if it means getting down to your level (and yes, I did). Ad hominem. So the real lesson you're trying to impart is to do as you say and not as you do? Well, I don't think any of you guys would hold out as long as I did. I think it's Not Nice to get personal. But there's a limit, one can't just ignore punches every day, and you're right, the above from me was ad hominem all the way (well, except that it doesn't concern any technical discussion, and that I'm not injecting noise but responding to such and trying to reduce it in the future, but still). Cheers, - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Thu, 11 Feb 2010 07:37:35 +0100, Alf P. Steinbach wrote: * Steven D'Aprano: s = [1] t = s # Binds the name t to the object bound to the name s. t[0] = 2 # Changes the object bound to the name t print(s) # Checks the object via the original name. Notice that your version describes what happens according to some implementation, below the level of the Python virtual machine. Consider just the assert( t is not s ) t = s Does this change anything at all in the computer's memory? If it doesn't, then it has no effect whatsoever. But since it does have an effect, a memory change has been effected. I don't think your disagreeing with Steven here - by talking about the computers memory, it's clear that you are talking about the details of an implementation of python, not the semantics of python itself. Unless, of course, you are under the misapprehension that the computer's memory is relevant to the python language, rather than the particular implementation. Python itself has nothing to do with computers or memory; these are mere implementation details. -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
On Tue, 09 Feb 2010 08:19:56 +0100, Alf P. Steinbach wrote: You don't have anything /but/ pointers in Python. x = 5 y = hello You want us to accept that the values of x and y are some mysterious pointer entities rather than the integer object 5 and the string object hello. At the point that your explanation depends on the reader understanding that the value of a variable x is not actually the thing that they assign to x, but some mysterious, invisible entity that exists entirely inside the implementation where the user can never reach, you probably should rethink your attachment to that explanation. No wonder so many Java programmers are still confused by it. It might help your case if we had a word for the thing that is actually assigned to the variable. In plain English that is value, but you want to use that for the pointer to the thing-that-we-otherwise-would-call- value, which leaves us no simple way to talk about the int 5 and string hello. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Modifying Class Object
* Steven D'Aprano:
On Tue, 09 Feb 2010 08:19:56 +0100, Alf P. Steinbach wrote:
You don't have anything /but/ pointers in Python.
x = 5
The above assigns to x a pointer to an object whose value is 5:
x -- 5
y = hello
Ditto result:
y -- hello
And if now do
x = y
then the code is assigning (copying) to x the pointer in y:
x ---
\
y -- hello
which you can check by
assert( x is y )
or
assert( id( x ) == id( y ) )
and which becomes essential to understand when that object is mutable...
Like:
x = [1, 2, 3, 4]
y = hello
y = x
y.append( 5 )
print( x )
You want us to accept that the values of x and y are some mysterious
pointer entities rather than the integer object 5 and the string object
hello.
The basics of pointers are simple.
You can copy pointers (assignment, argument), and you can check for equality
(is), and you can refer to the object that's pointed to (attribute access,
indexing, operators). And in CPython you can even obtain the pointer value as an
integer via id().
So there's nothing mysterious.
In particular
x = [1, 2, 3, 4]
y = x
does not copy the object value, it only copies the pointer.
That also matters for e.g.
x = 1000*A
y = x
And aliasing, like in the last three examples above, is pretty difficult to
understand without a pointer view of things.
And if aliasing is not understood, then forever stranded at beginner's level.
At the point that your explanation depends on the reader understanding
that the value of a variable x is not actually the thing that they assign
to x, but some mysterious, invisible entity that exists entirely inside
the implementation where the user can never reach, you probably should
rethink your attachment to that explanation. No wonder so many Java
programmers are still confused by it.
Thanks for thinking about my writings.
As it happens I've already written about pointers in chapter 2, although not
mentioning the word pointer. :-)
I made do with the term reference, because in Python there's not anything else
(in particular there's no pass by reference) that could cause confusion.
However, that cop-out (is that the right term?) wouldn't work for text based on
a language like C++, which has another kind of reference, or for that matter C#
which is like Python and Java except that C# also has pass by reference...
Some mixed feedbacks on that writing, but it's section 2.6.7 References
automatic garbage collection in ch 2 Basic concepts at url:
http://tinyurl.com/programmingbookP3 (I hope I typed the URL correctly).
It might help your case if we had a word for the thing that is actually
assigned to the variable. In plain English that is value, but you want
to use that for the pointer to the thing-that-we-otherwise-would-call-
value, which leaves us no simple way to talk about the int 5 and string
hello.
There are two values: the pointer value, and the object value.
In CPython:
a = blah
str.format( Pointer = {0}, object = {1}.format( id( a ), a ) )
'Pointer = 12090272, object = blah'
_
More simply, there's the pointer and there's the object pointed to.
Or, in the not-very-general-but-I-think-works-in-Python terminology that I used
in 2.6.7, there's the reference and there's the object.
So the thing that's actually assigned to a variable is in language-independent
terminology a pointer (or pointer value), although that doesn't mean C or
Pascal or whatever specific language pointer but just a copyable object
reference, and perhaps in Python-specific terminology it's just a reference.
I don't know better terms...
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
