Modifying Class Object
in [Python]
|
From: Alf P. Steinbach on 10 Feb 2010 15:02 * Duncan Booth: > "Alf P. Steinbach" <alfps(a)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
From: Alf P. Steinbach on 10 Feb 2010 15:14 * 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
From: Ethan Furman on 10 Feb 2010 13:38 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~
From: Steve Holden on 10 Feb 2010 16:14 Alf P. Steinbach wrote: > * Duncan Booth: >> "Alf P. Steinbach" <alfps(a)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/
From: Steven D'Aprano on 10 Feb 2010 16:46
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 |