Modifying Class Object
in [Python]
|
From: Alf P. Steinbach on 10 Feb 2010 18:34 * 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
From: Steve Holden on 10 Feb 2010 21:51 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/
From: Alf P. Steinbach on 10 Feb 2010 22:36 * 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
From: Steve Holden on 10 Feb 2010 22:49 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 Python it says > something like "unbound". Which means the same. > Be careful when comparing static and dynamic languages. Java, being a static language, has no equivalent to Python's NameError and AttributeError, which both represent situations in which no object has been bound to a name. In those cases it isn't that the name exists and is bound to a "null pointer", it's simply that the name doesn't exist. So there is no "copyable reference value". 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/
From: Steve Holden on 10 Feb 2010 23:19
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/ |