Modifying Class Object
T
missing. I have a class Test, for example:
class Test:
def __init__(self, param1, param2, param3):
self.param1 = param1
self.param2 = param2
self.param3 = param3
Next, I have a dictionary mytest that contains instances of Test. If
I want to modify one of the Test instances within my dictionary, I
have to rewrite the entire entry, correct (since Python passes by
value, not reference)? I.e. if I wish to change just param3 of an
instance, I would have to do:
def changevalue():
for key in mytest.keys():
currentparam = mytest[key]
param1 = currentparam.param1
param2 = currentparam.param2
param3 = currentparam.param3
param3 = "newvalue"
mytest[key] = Test(param1, param2, param3)
If there's an easier way to accomplish this that I'm missing, that'd
be great!
Chris Rebert
> Ok, just looking for a sanity check here, or maybe something I'm
> missing. I have a class Test, for example:
>
> class Test:
> def __init__(self, param1, param2, param3):
> self.param1 = param1
> self.param2 = param2
> self.param3 = param3
>
> Next, I have a dictionary mytest that contains instances of Test. If
> I want to modify one of the Test instances within my dictionary, I
> have to rewrite the entire entry, correct (since Python passes by
> value, not reference)?
Incorrect; Python uses neither. See
http://effbot.org/zone/call-by-object.htm for a excellent explanation
of what Python does use.
> I.e. if I wish to change just param3 of an
> instance, I would have to do:
>
> def changevalue():
> for key in mytest.keys():
> currentparam = mytest[key]
> param1 = currentparam.param1
> param2 = currentparam.param2
> param3 = currentparam.param3
> param3 = "newvalue"
> mytest[key] = Test(param1, param2, param3)
>
> If there's an easier way to accomplish this that I'm missing, that'd
> be great!
def changevalue():
for test in mytest.values():
test.param3 = "newvalue"
Cheers,
Chris
--
http://blog.rebertia.com
T
> On Sun, Feb 7, 2010 at 5:05 PM, T <misceveryth...@gmail.com> wrote:
> > Ok, just looking for a sanity check here, or maybe something I'm
> > missing. I have a class Test, for example:
>
> > class Test:
> > def __init__(self, param1, param2, param3):
> > self.param1 = param1
> > self.param2 = param2
> > self.param3 = param3
>
> > Next, I have a dictionary mytest that contains instances of Test. If
> > I want to modify one of the Test instances within my dictionary, I
> > have to rewrite the entire entry, correct (since Python passes by
> > value, not reference)?
>
> of what Python does use.
>
> > I.e. if I wish to change just param3 of an
> > instance, I would have to do:
>
> > def changevalue():
> > for key in mytest.keys():
> > currentparam = mytest[key]
> > param1 = currentparam.param1
> > param2 = currentparam.param2
> > param3 = currentparam.param3
> > param3 = "newvalue"
> > mytest[key] = Test(param1, param2, param3)
>
> > If there's an easier way to accomplish this that I'm missing, that'd
> > be great!
>
> def changevalue():
> for test in mytest.values():
> test.param3 = "newvalue"
>
> Cheers,
> Chris
> --http://blog.rebertia.com
Thanks so much - this makes life a lot easier! And a great reference
as well.
Cheers,
Doug
Steve Holden
mytest[key].param3 = "newvalue"
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/
Alf P. Steinbach
> On Sun, Feb 7, 2010 at 5:05 PM, T <misceve...@gmail.com> wrote:
>> Ok, just looking for a sanity check here, or maybe something I'm
>> missing. I have a class Test, for example:
>>
>> class Test:
>> def __init__(self, param1, param2, param3):
>> self.param1 = param1
>> self.param2 = param2
>> self.param3 = param3
>>
>> Next, I have a dictionary mytest that contains instances of Test. If
>> I want to modify one of the Test instances within my dictionary, I
>> have to rewrite the entire entry, correct (since Python passes by
>> value, not reference)?
>
> Incorrect; Python uses neither. See
> http://effbot.org/zone/call-by-object.htm for a excellent explanation
> of what Python does use.
Hm. While most everything I've seen at effbot.org has been clear and to the
point, that particular article reads like a ton of obfuscation.
Python passes pointers by value, just as e.g. Java does.
There, it needed just 10 words or so. :-) Or perhaps some more words to point
out that in the Java language spec those reference values are called pointers,
but that this terminology isn't (apparently) used for Python, and isn't even
well known among Java programmers. But that's just one extra little para.
One just has to be clear about exactly what it is that's passed by value.
Not Python objects, but references (pointers) to them, the id(o) values.
>> I.e. if I wish to change just param3 of an
>> instance, I would have to do:
>>
>> def changevalue():
>> for key in mytest.keys():
>> currentparam = mytest[key]
>> param1 = currentparam.param1
>> param2 = currentparam.param2
>> param3 = currentparam.param3
>> param3 = "newvalue"
>> mytest[key] = Test(param1, param2, param3)
>>
>> If there's an easier way to accomplish this that I'm missing, that'd
>> be great!
>
> def changevalue():
> for test in mytest.values():
> test.param3 = "newvalue"
Cheers,
- Alf
MRAB
A pointer tells you where something is; a reference doesn't.
Alf P. Steinbach
Depends on your choice terminology. I referred to the Java (language spec)
terminology to make it clear.
> A pointer tells you where something is; a reference doesn't.
Sorry, I don't know of any relevant terminology where that is the case.
Cheers & hth.,
- Alf
Steve Holden
This topic was discussed at great, nay interminable, length about a year
ago. I'd appreciate it if you would search the archives and read what
was said then rather than hashing the whole topic over again to nobody's
real advantage.
Steven D'Aprano
> Alf:
>
> This topic was discussed at great, nay interminable, length about a year
> ago. I'd appreciate it if you would search the archives and read what
> was said then rather than hashing the whole topic over again to nobody's
> real advantage.
Curse you Steve, I had just come up with a brilliant rebuttal of Alf's
position. It was sheer genius, the sort of thing that would have James
Gosling weeping with envy.
Oh well, into the bitbucket it goes...
--
Steven
alex23
> Hm. While most everything I've seen at effbot.org has been clear and to the
> point, that particular article reads like a ton of obfuscation.
Must. Resist. Ad hominem.
> Python passes pointers by value, just as e.g. Java does.
>
> There, it needed just 10 words or so. :-)
10 words _plus_ an understanding of Java. Do you really think its
appropriate to discuss Python's behaviour purely in terms of other
languages?
Further, you've managed to define Python's behaviour as being somehow
_both_ of the major evaluation strategies - calling a reference by
value - so you're asking people to understand two totally irrelevant
models just to avoid describing one in its own terms. Rather than
arguing about whether you have a 'value' or a 'reference', it's a lot
easier to explain that you're passing mutable & immutable objects
around. The behaviour is thus defined in terms of the object and _not_
in the calling model, and is far more consistent with object
references throughout the language. It also doesn't require reference
to other languages simply to define Python's model in terms of what it
isn't.
Alf P. Steinbach
Well that's my point, and thanks for backing me up on that :-): it's very
simple, and as demonstrated can be expressed in 10 words or less (plus perhaps a
terminology reference, as I did above), so all that discussion and in particular
the lengthy article at effbot serves as obfuscation and nothing else.
By the way, most every programming language has some corner like that, something
that is utterly simple but somehow has some kind of obfuscation-meme attached.
In C++ it's "call" and "constructor". It doesn't help that the language's
standard lays down the law on it, it doesn't help that the language's creator
has laid down the law, it doesn't help that it's utterly and completely simple.
Somehow newbies and even some experienced people manage to create their own
terminological nightmare and drawing conclusions about reality from that
misguided obfuscated view, and then discussing it up and down and sideways.
Steven D'Aprano
> Python passes pointers by value, just as e.g. Java does.
How do I get a pointer in pure Python code (no ctypes)? I tried both
Pascal and C syntax (^x and *x), but both give syntax errors.
For that matter, how do I get a pointer in Java code?
If Python doesn't have pointers, then why are you talking about Python
passing pointers? It's a vacuous truth, like saying that Python passes
dinosaurs by name.
--
Steven
T
was actually a shelve file, not a dictionary..so just re-assigning the
variable isn't working, but re-writing the object to the shelve file
does. So in this case, is there any way to just change a single
value, or am I stuck rewriting the entry?
Steven D'Aprano
>> A pointer tells you where something is; a reference doesn't.
>
> Sorry, I don't know of any relevant terminology where that is the case.
Taken from Wikipedia:
"A pointer is a simple, less abstracted implementation of the more
abstracted reference data type (although it is not as directly usable as
a C++ reference)."
http://en.wikipedia.org/wiki/Pointer_(computing)
In other words, a pointer is a specific type of reference. A reference in
turn is an opaque but low-level data type which "refers to" in some way
to the data you actually care about. (C++ has a concrete reference type,
which is not to be confused with abstract references.)
http://en.wikipedia.org/wiki/Reference_(computer_science)
Unless otherwise stated, references are opaque and coders need not care
how the reference mechanism is implemented, see e.g.:
http://www.cocoabuilder.com/archive/cocoa/20777-opaque-reference.html
In Python you don't use references directly, there is no reference type
or object. You can simulate the semantics of references (but not
pointers) by putting your object in a list and passing the list around.
--
Steven
Alf P. Steinbach
> On Mon, 08 Feb 2010 02:51:05 +0100, Alf P. Steinbach wrote:
>
>> Python passes pointers by value, just as e.g. Java does.
>
> How do I get a pointer in pure Python code (no ctypes)? I tried both
> Pascal and C syntax (^x and *x), but both give syntax errors.
Well, I don't believe that you tried that. :-)
From one point of view it's extremely easy: just create some object, even just
type 42 as an integer literal, and you can apply all of Python's pointer
operations to the result -- which isn't much, basically just checking for
pointer equality via 'is' or applying 'id' to get a value that represents the
pointer uniquely, or copying the pointer via assignment or parameter passing.
Whether you can obtain the bits of the internal pointer value, represented as
e.g. an int, formally depends on the Python implementation.
In CPython the 'id' function provides the internal pointer value as an int.
I.e., with CPython you can do
def foo( o ):
print( id( o ) ) # Shows the pointer value in decimal.
whatever = 42
print( id( whatever ) ) # Shows the pointer value in decimal.
foo( whatever ) # Shows the exact *same* pointer value.
which at a slightly higher level of abstraction works just as well with any
conceivable Python implementation, although you have no formal guarantee that
the conceptual "pointer" values are actually the internally memory addresses.
But, in CPython they are, and you run into them all the time, for example (where
the "at" tells you that it's a memory location specification, a pointer),
>>> import turtle
>>> turtle.forward
<function forward at 0x00DB7D20>
>>>
>>> id( turtle.forward )
14384416
>>> hex( id( turtle.forward ) )
'0xdb7d20'
>>> _
> For that matter, how do I get a pointer in Java code?
As with Python, from one point of view it's extremely easy, just 'new' some
object, and then you can apply all of Java's pure pointer operations to the
result -- which isn't much, basically just checking for pointer equality and
copying a pointer via assignment or parameter passing.
In Java it's a pointer by definition, namely the language spec's definition.
From another point of view, getting at the internal representation of the
pointer is a bit harder in Java than in Python, at least as far as I know. It
may not be practically possible. Disclaimer: I'm not a Java expert, and haven't
used Java for years, and it just might be possible by using JNI (Java Native
Interface), but that requires you to write a dynamic library in e.g. C or C++,
and as I recall Java just creates a kind of fixed reference for the duration of
a JNI call so the JNI side of things may not tell you anything about the Java
side of things before or after the call.
But if it helps, just to learn about pointers in various languages you -- or
rather, some other reader, because I suspect that you know this already! :-) --
might look at <url: http://cslibrary.stanford.edu/106/>.
It contains a simple pointers example expressed in four different languages,
namely C, C++, Pascal and Java, in particular comparing C and Java.
> If Python doesn't have pointers, then why are you talking about Python
> passing pointers? It's a vacuous truth, like saying that Python passes
> dinosaurs by name.
See above.
Alf P. Steinbach
Yes, sort of.
The last paragraph however confuses two different meanings of "reference".
So when using terms such as "reference" it helps to refer :-) to some specific
terminology, unless that's clearly understood from context.
Cheers,
- Alf
Arnaud Delobelle
> * Chris Rebert:
>> On Sun, Feb 7, 2010 at 5:05 PM, T <misceve...@gmail.com> wrote:
>>> Ok, just looking for a sanity check here, or maybe something I'm
>>> missing. I have a class Test, for example:
>>>
>>> class Test:
>>> def __init__(self, param1, param2, param3):
>>> self.param1 = param1
>>> self.param2 = param2
>>> self.param3 = param3
>>>
>>> Next, I have a dictionary mytest that contains instances of Test. If
>>> I want to modify one of the Test instances within my dictionary, I
>>> have to rewrite the entire entry, correct (since Python passes by
>>> value, not reference)?
>>
>> Incorrect; Python uses neither. See
>> http://effbot.org/zone/call-by-object.htm for a excellent explanation
>> of what Python does use.
>
> Hm. While most everything I've seen at effbot.org has been clear and
> to the point, that particular article reads like a ton of obfuscation.
>
> Python passes pointers by value, just as e.g. Java does.
Please! Not this again! This has been discussed to death and beyond more
than enough times. Go search the c.l.p archives, read it all, and I'm
sure you won't want to add anything anymore.
--
Arnaud
Gerard Flanagan
+1 !!
Duncan Booth
Either open the shelve with writeback=True or rewrite the entry.
Rewriting the entry isn't hard: you can just re-use the same value:
def changevalue():
for key in mytest.keys():
temp = mytest[key]
temp.param3 = "newvalue"
mytest[key] = temp
If you really are changing every item in the shelve using writeback=True
will be much simpler, but if you are only changing a few then just tell the
shelve that you've updated them as above.
--
Duncan Booth http://kupuguy.blogspot.com
Steve Holden
Steve Holden
> * Steve Holden:
[...]
>> Alf:
>>
>> This topic was discussed at great, nay interminable, length about a year
>> ago. I'd appreciate it if you would search the archives and read what
>> was said then rather than hashing the whole topic over again to nobody's
>> real advantage.
>
> Well that's my point, and thanks for backing me up on that :-): it's
> very simple, and as demonstrated can be expressed in 10 words or less
> (plus perhaps a terminology reference, as I did above), so all that
> discussion and in particular the lengthy article at effbot serves as
> obfuscation and nothing else.
>
considerable ignorance of issue that were extremely nuanced. Whatever
point you were trying to make was lost in your self-aggrandizing
disrespect of Fredrik Lundh, a software engineer of some repute with a
long history of contribution to Python. The fact that your post was
basically a restatement of one of the several competing positions in
that thread makes it no more right than any of the others.
> By the way, most every programming language has some corner like that,
> something that is utterly simple but somehow has some kind of
> obfuscation-meme attached.
>
Why thank you for the education. Somehow in my 40-odd years of
programming I had quite overlooked that fact. Which helps how?
> In C++ it's "call" and "constructor". It doesn't help that the
> language's standard lays down the law on it, it doesn't help that the
> language's creator has laid down the law, it doesn't help that it's
> utterly and completely simple. Somehow newbies and even some experienced
> people manage to create their own terminological nightmare and drawing
> conclusions about reality from that misguided obfuscated view, and then
> discussing it up and down and sideways.
>
Which IMHO you have done little to assist. Just how exactly *do* we
succeed in asking you not to discuss something?
yours intemperate-ly - steve
Steve Holden
>
+1000
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Steve Holden:
> [...]
>>> Alf:
>>>
>>> This topic was discussed at great, nay interminable, length about a year
>>> ago. I'd appreciate it if you would search the archives and read what
>>> was said then rather than hashing the whole topic over again to nobody's
>>> real advantage.
>> Well that's my point, and thanks for backing me up on that :-): it's
>> very simple, and as demonstrated can be expressed in 10 words or less
>> (plus perhaps a terminology reference, as I did above), so all that
>> discussion and in particular the lengthy article at effbot serves as
>> obfuscation and nothing else.
>>
> Please don't assume I was trying to support you. Your remarks showed
> considerable ignorance of issue that were extremely nuanced. Whatever
> point you were trying to make was lost in your self-aggrandizing
> disrespect of Fredrik Lundh, a software engineer of some repute with a
> long history of contribution to Python. The fact that your post was
> basically a restatement of one of the several competing positions in
> that thread makes it no more right than any of the others.
What on Earth are you babbling about?
Perhaps next you'll drag in the Pope, saying I've shown him some disrespect.
News for you: the Pope ain't participating.
>> By the way, most every programming language has some corner like that,
>> something that is utterly simple but somehow has some kind of
>> obfuscation-meme attached.
>>
> Why thank you for the education. Somehow in my 40-odd years of
> programming I had quite overlooked that fact. Which helps how?
>
>> In C++ it's "call" and "constructor". It doesn't help that the
>> language's standard lays down the law on it, it doesn't help that the
>> language's creator has laid down the law, it doesn't help that it's
>> utterly and completely simple. Somehow newbies and even some experienced
>> people manage to create their own terminological nightmare and drawing
>> conclusions about reality from that misguided obfuscated view, and then
>> discussing it up and down and sideways.
>>
> Which IMHO you have done little to assist. Just how exactly *do* we
> succeed in asking you not to discuss something?
That's just a silly as the above. Hello? *Not* discuss an on-topic topic?
Anyways, we haven't reached discussion yet, if it will ever come to that.
All I see is a lot of silly noise about a simple trivially true technical
statement, with incoherent allegations of disrespect to the Pope, the current
king of France, and whomever, unfortunately as usual in this group. :-(
T
Duncan - Thanks for your help. So each of the shelve entries I'm
modifying look something like this: myshelve[key] =
TestClassObject(param1, param2, param3, param4, param5, etc.). In
this case, with quite a few parameters, would you suggest setting
writeback=True and just modifying the needed value, or rewriting the
entire entry? I have to admit the writeback option looks good, and if
the TestClassObject format ever changes (i.e. if I ever change the
order of the params), this particular function will be unchanged.
However, I don't know what the performance hit would be in using it.
Duncan Booth
> Duncan - Thanks for your help. So each of the shelve entries I'm
> modifying look something like this: myshelve[key]
> this case, with quite a few parameters, would you suggest setting
> writeback=True and just modifying the needed value, or rewriting the
> entire entry? I have to admit the writeback option looks good, and if
> the TestClassObject format ever changes (i.e. if I ever change the
> order of the params), this particular function will be unchanged.
> However, I don't know what the performance hit would be in using it.
Only you know your data and pattern of use. Try a few tests to get a feel
of the trade-offs between explicitly flagging items as changed or using
writeback=True.
Diez B. Roggisch
Whao. You just needed 10 words, plus a paragraph to explain something in
terms of a spec that's just about 600 pages strong. Amazing display of
conciseness, and certainly the most valuable thing for some programming
newbie to work with. Thanks!
Diez
Alf P. Steinbach
I apologize for assuming that "pointer" is a known word to [c.l.p.] denizens.
But, if it can help, although for clarity I had to provide a concrete reference,
you don't need to read the complete Java language spec to understand that word.
Just Google it.
Cheers & hth.,
- ALf
Alf P. Steinbach
> "Alf P. Steinbach" <al...@start.no> wrote:
>> Hm. While most everything I've seen at effbot.org has been clear and to the
>> point, that particular article reads like a ton of obfuscation.
>
> Must. Resist. Ad hominem.
>
>> Python passes pointers by value, just as e.g. Java does.
>>
>> There, it needed just 10 words or so. :-)
>
> 10 words _plus_ an understanding of Java.
No, one only needs an understanding of "pointer".
"Pointer" is a mostly language independent concept.
The reference to the Java language spec, where that term is used for this, was
just an unsuccessful attempt to keep out word-play arguments based on the
incompatibility of some incompatible meaning of "pointer"...
MRAB
> On Mon, 08 Feb 2010 02:51:05 +0100, Alf P. Steinbach wrote:
>
>> Python passes pointers by value, just as e.g. Java does.
>
> How do I get a pointer in pure Python code (no ctypes)? I tried both
> Pascal and C syntax (^x and *x), but both give syntax errors.
>
MRAB
The Pope isn't (as far as we know) a Pythonista.
Steve Holden
[...]
> P.S. I couldn't resist. :(
>
And here I was, sitting on my hands ... but someone was wrong on the
Internet, so D'Aprano had to put them right. Your fatal weakness.
Of course this won't make the slightest difference. "'When I use a
word,' said Humpty ..."
regards
Steve
MRAB
> On Mon, Feb 8, 2010 at 6:42 PM, Steve Holden <st...@holdenweb.com
> <mailto:st...@holdenweb.com>> wrote:
>
> Stephen Hansen wrote:
> [...]
> > P.S. I couldn't resist. :(
> >
>
> And here I was, sitting on my hands ... but someone was wrong on the
> Internet, so D'Aprano had to put them right. Your fatal weakness.
>
> Of course this won't make the slightest difference. "'When I use a
> word,' said Humpty ..."
>
>
>
> First, someone thought I was you.
>
> Now you think I'm D'Aprano.
>
> I'm just gonna go by Bob for now on.
>
> :)
>
> --B
>
Bruce would be less confusing. :-)
Alf P. Steinbach
>
> [snip]
> To say, "pass by value" implies things to people. It describes a sort of
> world where I'm a function about to do some work, and on my desk I have
> a series of boxes with names on it. It describes an environment where
> someone comes over and drops something into each of my boxes. The
> contents of these boxes are mine alone!
Then, when the imprecision makes people misunderstand, one should not say that.
One should then be more precise.
One should say /what/ is passed by value.
[snip]
> >>> import copy
> >>> def doit(a):
> ... a += a
> ... return a
> ...
> >>> test1 = 1
> >>> test2 = doit(test1)
> >>> test1
> 1
> >>> test2
> 2
> >>> test3 = [1]
> >>> test4 = doit(test3)
> >>> test3
> [1, 1]
> >>> test4
> [1, 1]
>
> I know you already know this, but the point is: you're -hurting- other
> peoples understanding by using terms like this that don't apply to
> Python's specific nature.
The terms apply very well to Java. And Java has the identical parameter passing
mechanism for class type objects. Hence, the argument is bogus.
Cheers & hth.,
- Alf
PS: I cannot see any of your postings on Usenet. So I just sort of grabbed this
from GMane and posted to Usenet. Hopefully you'll see it back at the list. :-)
Terry Reedy
> I apologize for assuming that "pointer" is a known word to [c.l.p.]
> denizens.
It is irrelevant.
Python calls Python functions by associating argument objects (or
objects derived therefrom) with paramenter names, very much like
assigment statements.
If one understands Python objects, names, and assignment statements,
which one must to understand Python, this completely explains the
function calls, function execution, and its effect on passed objects.
All Python expressions evaluate to an object. Call expressions evaluate
to the object returned by the function.
Different interpreters implement call and return differently. Certainly,
most humans do not use C pointers when they mentally execute Python code.
Terry Jan Reedy
Alf P. Steinbach
> On 2/8/2010 2:10 PM, Alf P. Steinbach wrote:
>
>> I apologize for assuming that "pointer" is a known word to [c.l.p.]
>> denizens.
>
> It is irrelevant.
>
> Python calls Python functions by associating argument objects (or
> objects derived therefrom) with paramenter names, very much like
> assigment statements.
Well, part of the above is word-play. When a name refers to an object elsewhere
and that reference can be copied around, then it is a pointer to the object in
e.g. the Java sense, which I very purposefully referenced to be clear about it.
So you're saying that X is irrelevant in Python because Python uses Y, where Y
is a description of X...
But part of what you write puzzles me.
As far as the language spec is concerned the argument passing mechanism seems to
me to be identical to assignments, not just "very much like".
Your phrase "or objects derived therefrom" seems to imply that immutable objects
can be copied (an optimization that once was rejected), but as far as I can see
the language spec only talks about binding with no provision for binding to do
anything else than making a name refer directly to a specified object,
presumably with *the same id*.
Not talking about things built on top of argument passing like *, and not
talking about scopes or other (in this context) extraneous details: is there
something I've overlooked in the basic mechanism?
> If one understands Python objects, names, and assignment statements,
> which one must to understand Python, this completely explains the
> function calls, function execution, and its effect on passed objects.
Yes.
There are many ways to understand it though.
The simplest description, reality, that names refer to objects, where those
references can be copied, i.e. that they in e.g. the Java sense are pointers to
objects, seems to be simplest -- and is certainly shortest. :-)
> All Python expressions evaluate to an object. Call expressions evaluate
> to the object returned by the function.
>
> Different interpreters implement call and return differently. Certainly,
> most humans do not use C pointers when they mentally execute Python code.
The Java language spec reference for "pointer" was to avoid arguments about
irrelevant specialized meanings of the term, such as C pointers.
Steven D'Aprano
> * Stephen Hansen -> Alf P. Steinbach:
>>
>> [snip]
>> To say, "pass by value" implies things to people. It describes a sort
>> of world where I'm a function about to do some work, and on my desk I
>> have a series of boxes with names on it. It describes an environment
>> where someone comes over and drops something into each of my boxes. The
>> contents of these boxes are mine alone!
>
> Then, when the imprecision makes people misunderstand, one should not
> say that.
>
> One should then be more precise.
>
> One should say /what/ is passed by value.
I don't see how that matters. Python's behaviour is EXACTLY the same, no
matter what you pass to the function.
You don't pass pointers in Python, because you, the Python author, have
no way of specifying a pointer in Python code. It is *always* an object
that you pass, by giving a literal, the name an object is bound to, or
some other expression that returns an object:
function( my_object )
function( 12345 )
function( ham(3) + spam(5) )
If you're talking to the person who writes Python code, then you should
discuss the sorts of things that exist in Python: objects and names and
expressions, but no pointers.
If you're talking about the Python virtual machine, instead of the high-
level Python code, then you should say so -- but there are still no
pointers in the VM. Look at the output of dis.dis and you will see
objects pushed onto a stack, but no pointers.
It's not until you get past the level of Python code, past the virtual
machine, and into the implementation of the virtual machine, that you
will finally find pointers.
But why stop there? If somebody asks you a question about Python, and you
choose to ignore them and answer a different question about one
particular implementation's internals instead, I don't see why you stop
there. Why not go down another layer and talk about copying bytes, or two
layers and answer that Python does call-by-bit-flipping, or a layer below
that and say it's all done by varying potential differences?
You shouldn't expect your listener to understand machine code to
understand Python's high-level behaviour, nor should you expect them to
be C coders. You don't need to understand pointers to understand a
language that doesn't support them.
[...]
> The terms apply very well to Java. And Java has the identical parameter
> passing mechanism for class type objects. Hence, the argument is bogus.
Everything I've said applies to Java as well, and the argument about call-
by-whatever is just as prevalent in Java circles as in Python.
Example #1:
Q: If Java uses the pass-by reference, why won't a swap
function work?
A: Your question demonstrates a common error made by Java
language newcomers. Indeed, even seasoned veterans find
it difficult to keep the terms straight.
Java does manipulate objects by reference, and all
object variables are references. However, Java doesn't
pass method arguments by reference; it passes them by
value.
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
Example #2:
Myth: "Objects are passed by reference, primitives are
passed by value"
Some proponents of this then say, "Ah, except for immutable
objects which are passed by value [etc]" which introduces
loads of rules without really tackling how Java works.
http://www.yoda.arachsys.com/java/passing.html
Example #3:
Java is Pass-by-Value, Dammit!
http://javadude.com/articles/passbyvalue.htm
Java programmers suffer for a bad mental model just as much as Python
programmers.
All this is because of two conceptual mistakes: (1) the Java community
has conflated the internals of what happens in the implementation of the
Java VM with high-level Java code; and (2) a refusal to accept that there
are calling strategies other than pass-by-value and pass-by-reference.
--
Steven
Alf P. Steinbach
> On Mon, Feb 8, 2010 at 8:01 PM, Alf P. Steinbach <al...@start.no
> <mailto:al...@start.no>> wrote:
>
> * Stephen Hansen -> Alf P. Steinbach:
>
>
> [snip]
>
> To say, "pass by value" implies things to people. It describes a
> sort of world where I'm a function about to do some work, and on
> my desk I have a series of boxes with names on it. It describes
> an environment where someone comes over and drops something into
> each of my boxes. The contents of these boxes are mine alone!
>
>
> Then, when the imprecision makes people misunderstand, one should
> not say that.
>
> One should then be more precise.
>
> One should say /what/ is passed by value.
>
>
>
> One should not use the phrase that is fundamentally imprecise.
>
> The phrase "pass by value" means something different then the phrase
> "pass by object" aka "pass by sharing". They are in many cases very
> similar. They are not the same.
Right.
"pass by value" is a lower level notion.
And as you show below, in the paragraph marked [1], it can be used to describe
call by sharing very succinctly and precisely, just as I did... ;-)
> Using it is simply wrong. There is
> really no legitimate argument you can make otherwise: even in languages
> where call-by-value IS the norm, the phrase is imprecise enough to
> confuse people, as the semantics of what call-by-value mean to a
> language vary. But those semantics do NOT apply to Python.
In a way that's right, but only at the level of abstraction of pass by sharing.
At that level it's wrong to say that pass by sharing is pass by value (as they
reportedly do over in Java-land), just as, at that level, it's wrong to say that
pass by reference is pass by value notwithstanding that some kind of value must
be copied in the internal implementation.
Describing pass by sharing in terms of pass by value is however very simple and
legitimate, involving a higher level described in terms of a lower level -- as
you illustrate right below: <g>
> [snip]
> I know you already know this, but the point is: you're -hurting-
> other peoples understanding by using terms like this that don't
> apply to Python's specific nature.
> The terms apply very well to Java. And Java has the identical
> parameter passing mechanism for class type objects. Hence, the
> argument is bogus.
>
>
> [1] Java uses silly terminology; and that it chooses to use silly
> terminology in no way impacts the validity of the argument. Java isn't
> an authority. Python's been around longer! And the specific behavior
> here, "call by value where the value is an object reference" was named
> "call by sharing" back in the 1970's by Liskov.
Yep.
As you write, "call by sharing" can be described as "call by value where the
value is an object reference".
Althuogh I'd rather use "where the value is an object pointer", because the word
"pointer" already denotes a copyable value so doesn't make the head spin...
> Java isn't call-by-value (for objects) either, even if that phrase is
> common in the Java community.
Right, and here the parenthesis (for objects) establishes which abstraction level.
> C is call-by-value. VB is, I believe,
> call-by-value -- though I may be wrong here, as I only sort of blinked
> at VB a long, long time ago.
Full VB supports both call by sharing and call by reference.
> Its distinct. Its different. Its neither call-by-value, nor
> call-by-reference. The /value/ of a thing is NOT its identity. Its the
> /state/ of that thing.
Talking about a reference value (a.k.a. pointer), as you do earlier above in
[1], does not mean that one is talking about a Python object value.
So essentially the paragraph immediately above seems to be a confusion based on
multiple meanings of "value", unless it's just a description of Python objects?
> By your argument, call-by-reference is call-by-value too! Because you're
> passing "a value" -- but you're -always- going to pass some piece of
> data, otherwise you're not actually passing anything.
No, whatever you think my argument is (no quote, so I'm left in the dark about
that assumption) here you're back to confusing levels of abstraction again.
Call by reference is necessarily, at some level, implemented in terms of call by
value.
That doesn't make call by reference the same as call by value, not more than the
human body is one giant molecule just because it consists of molecules.
> The /by value/ vs /by reference/ vs /by sharing/ is not about "is a
> value being passed", in all cases, "a value" is. By Value means a copy
> of the thing is made. By Reference means you're accessing the callers
> variable directly. By Sharing means you're both sharing the same object.
Yes, violent agreement.
> PS: I cannot see any of your postings on Usenet. So I just sort of
> grabbed this from GMane and posted to Usenet. Hopefully you'll see
> it back at the list. :-)
>
>
> I've heard that before, and have no idea why, nor any real interest in
> solving it: I don't want to read cpl via Usenet, and prefer to read it
> as a mailing list. Somewhere between Gmail->python.org->python.org
> <http://python.org>'s usenet server->the world, some people don't seem
> to get my posts. Yet it shows up on some news servers, not others.
>
> No idea. Nothing I know of can solve it.
Not sure, but perhaps it's possible to mail directly to gmane?
Alf P. Steinbach
> On Tue, 09 Feb 2010 05:01:16 +0100, Alf P. Steinbach wrote:
>
>> * Stephen Hansen -> Alf P. Steinbach:
>>> [snip]
>>> To say, "pass by value" implies things to people. It describes a sort
>>> of world where I'm a function about to do some work, and on my desk I
>>> have a series of boxes with names on it. It describes an environment
>>> where someone comes over and drops something into each of my boxes. The
>>> contents of these boxes are mine alone!
>> Then, when the imprecision makes people misunderstand, one should not
>> say that.
>>
>> One should then be more precise.
>>
>> One should say /what/ is passed by value.
>
> I don't see how that matters. Python's behaviour is EXACTLY the same, no
> matter what you pass to the function.
>
> You don't pass pointers in Python, because you, the Python author, have
> no way of specifying a pointer in Python code. It is *always* an object
> that you pass, by giving a literal, the name an object is bound to, or
> some other expression that returns an object:
>
> function( my_object )
> function( 12345 )
> function( ham(3) + spam(5) )
Every name and literal above (and in Python generally) stands for a copyable
reference to an object, not for the object itself. You can copy the reference:
a = [123]
b = a
assert( a is b ) # Doesn't matter if mutable or immutable or what.
A copyable reference is a pointer. That is, a "pointer", in e.g. the Java sense,
and in the general language independent sense, means a copyable reference --
as illustrated e.g. in the Stanford computer science 101 course page I
referred you to earlier, with C versus Java pointers illustrated in the concrete.
Hence, since every name and literal above stands for a copyable reference, and
since a copyable reference is a pointer, every name and literal above stands for
a pointer -- that's /all/ that you handle directly in Python, namely pointers.
But if that terminology sounds bad or has too strong C-vibes or Java-vibes or
whatever, then we just need some other term for a Python "copyable reference".
> If you're talking to the person who writes Python code, then you should
> discuss the sorts of things that exist in Python: objects and names and
> expressions, but no pointers.
Well, given this terminology debate we may need some other term.
But IMHO the horse drawing the wagon needs to be mentioned to the potential
wagon driver, whatever that horse is called -- fourfooter, drawing-animal...
Anything else seems just senseless, meaningless abstraction, replacing one
simple single concept with a load of connections and special case rules.
> If you're talking about the Python virtual machine, instead of the high-
> level Python code, then you should say so -- but there are still no
> pointers in the VM. Look at the output of dis.dis and you will see
> objects pushed onto a stack, but no pointers.
I don't think you will see any Python objects pushed on the stack. But you will
see copyable object references pushed on the stack. That is, you will see
pointers pushed on the stack.
> It's not until you get past the level of Python code, past the virtual
> machine, and into the implementation of the virtual machine, that you
> will finally find pointers.
There too.
> But why stop there? If somebody asks you a question about Python, and you
> choose to ignore them and answer a different question about one
> particular implementation's internals instead, I don't see why you stop
> there. Why not go down another layer and talk about copying bytes, or two
> layers and answer that Python does call-by-bit-flipping, or a layer below
> that and say it's all done by varying potential differences?
I think a good professional programmer knows about all these levels.
Unfortunately, at least about 10 years ago students fresh out of college in
Norway did not know about "internal" things such as call stacks, which led them
to adopt many Unholy Programming Practices and to be Extremely Baffled by things
such as stack traces.
> You shouldn't expect your listener to understand machine code to
> understand Python's high-level behaviour, nor should you expect them to
> be C coders. You don't need to understand pointers to understand a
> language that doesn't support them.
From the above comments it seems you're thinking about C pointers. To prevent
that misconception I've defined the term "pointer" in every or most every
posting I've made in this thread, including this posting. I've also posted a
link to a Stanford University page with a simple-words explanation (they even
have an animated Bunny video, although I've not looked at it); it's CS 101.
You don't have anything /but/ pointers in Python.
So pointers are key -- by whatever name.
[snip]
> Java programmers suffer for a bad mental model just as much as Python
> programmers.
Yes. :-)
> All this is because of two conceptual mistakes: (1) the Java community
> has conflated the internals of what happens in the implementation of the
> Java VM with high-level Java code; and (2) a refusal to accept that there
> are calling strategies other than pass-by-value and pass-by-reference.
I'm not entirely sure about causes, but there is a tendency in general for
humans to go from one extreme to another that they regard as "opposite". Using
the term "call by value" for the Java (and Python) parameter passing is just
Wrong(TM), at least without a clear understanding of what can be passed. Using
"call by value" in a description of that model, mentioning very clearly what's
passed, is on the other hand very practical: it's short, succinct & correct.
Steven D'Aprano
> 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
Alf P. Steinbach
> 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 = 10000000*"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
Duncan Booth
> A copyable reference is a pointer. That is, a "pointer", in e.g. the
> Java sense,
> and in the general language independent sense, means a copyable
> reference -- as illustrated e.g. in the Stanford computer science
> 101 course page I
> referred you to earlier, with C versus Java pointers illustrated in
> the concrete.
The fact that C style pointers are used internally is an detail of the
CPython implementation.
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.
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.
The terminology of 'objects', 'names', 'references' describes an abstract
machine. The Python runtime can implement it in any way it chooses so long
as those semantics are preserved. One implementation involves 'pointers',
but that word implies other baggage which is not a required part of the
model.
Steve Holden
D'Aprano-like (I have these feeling I just insulted you both with one
sentence).
Steve Holden
> * Stephen Hansen:
[...]
>> I've heard that before, and have no idea why, nor any real interest in
>> solving it: I don't want to read cpl via Usenet, and prefer to read it
>> as a mailing list. Somewhere between Gmail->python.org->python.org
>> <http://python.org>'s usenet server->the world, some people don't seem
>> to get my posts. Yet it shows up on some news servers, not others.
>>
>> No idea. Nothing I know of can solve it.
>
> Not sure, but perhaps it's possible to mail directly to gmane?
>
Steve Holden
> On Mon, Feb 8, 2010 at 10:35 PM, Alf P. Steinbach <al...@start.no
> <mailto:al...@start.no>> wrote:
>
> Right.
>
> "pass by value" is a lower level notion.
>
> And as you show below, in the paragraph marked [1], it can be used
> to describe call by sharing very succinctly and precisely, just as I
> did... ;-)
>
>
> "reference" when speaking of programming languages, and using both
> together just compounds that. They are loaded words. The phrase "call my
> value where value is an object reference" is not clear, not obvious, not
> helpful. It requires far too much explanation of every single word
> there, depending on the background of who you are speaking to, to
> explain how it does not exactly use any of the words in a way which the
> person may be expecting, and making sure they understand that it does
> not imply anything that those words usually imply.
>
> I'm not even going to bother further-- I shouldn't have to begin with--
> your entire post is full of arguments with no more weight then, "I say
> this means that, and its clearer" with absolutely no regard for the fact
> that all of these words have weight and meaning to the world outside of
> your head.
>
[several paragraphs-worth of bothering further]
So you didn't believe me when I said
> Of course this won't make the slightest difference. "'When I use a
> word,' said Humpty ..."
regards
Terry Reedy
> As far as the language spec is concerned the argument passing mechanism
> seems to me to be identical to assignments, not just "very much like".
Except for the cross-namespace nature of the assignment, yes. Glad you
agree.
> Your phrase "or objects derived therefrom" seems to imply that immutable
> objects can be copied
No. Given
def f(*args, **kwds): print(args, kwds)
the objects bound to args and kwds are a tuple and dict *derived* from
(that collect together) the objects passed.
Terry Jan Reedy
Alf P. Steinbach
> "Alf P. Steinbach" <al...@start.no> wrote:
>
>> A copyable reference is a pointer. That is, a "pointer", in e.g. the
>> Java sense,
>> and in the general language independent sense, means a copyable
>> reference -- as illustrated e.g. in the Stanford computer science
>> 101 course page I
>> referred you to earlier, with C versus Java pointers illustrated in
>> the concrete.
>
> The fact that C style pointers are used internally is an detail of the
> CPython implementation.
Your statement seems pretty irrelevant to anything.
It's almost hilarious, quoting a single paragraph about how irrelevant the C
pointer is, and responding with something like that.
Do you understand that you're restating (in the form of exemplifying) what
you're quoting?
> 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.
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.
> The terminology of 'objects', 'names', 'references' describes an abstract
> machine. The Python runtime can implement it in any way it chooses so long
> as those semantics are preserved. One implementation involves 'pointers',
It seems that you're thinking of C pointers.
That's pretty dumb since
(1) it doesn't make sense, and
(2) it has been mentioned in almost every article in this thread, including
my first, and including the single paragraph that *you quoted above*,
which was only about that, that
we're not talking about C pointers here.
Python names denote pointers by definition (of pointer).
> but that word implies other baggage which is not a required part of the
> model.
The word itself doesn't imply other baggage, no.
It might help to *read* what you're quoting, try to follow references, so on.
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Stephen Hansen:
> [...]
>>> I've heard that before, and have no idea why, nor any real interest in
>>> solving it: I don't want to read cpl via Usenet, and prefer to read it
>>> as a mailing list. Somewhere between Gmail->python.org->python.org
>>> <http://python.org>'s usenet server->the world, some people don't seem
>>> to get my posts. Yet it shows up on some news servers, not others.
>>>
>>> No idea. Nothing I know of can solve it.
>> 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.
Cheers,
- Alf
Steve Holden
insisted on proposing a solution to a problem that he clearly stated he
had no interest in. I'm not quite sure, given that, what the point of
the advice was.
However, my question was genuine, based on your observed behavior. I
agree I might have phrased it more politely, but I do find your
self-assurance somewhat irritating.
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> * Steve Holden:
>>> Alf P. Steinbach wrote:
>>>> * Stephen Hansen:
>>> [...]
>>>>> I've heard that before, and have no idea why, nor any real interest in
>>>>> solving it: I don't want to read cpl via Usenet, and prefer to read it
>>>>> as a mailing list. Somewhere between Gmail->python.org->python.org
>>>>> <http://python.org>'s usenet server->the world, some people don't seem
>>>>> to get my posts. Yet it shows up on some news servers, not others.
>>>>>
>>>>> No idea. Nothing I know of can solve it.
>>>> 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,
* projection (at least the way I read it), and
* inject - noise - about - something - completely - irrelevant
Note that readers can easily guess about motivations for the last.
> 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,
sorry.
> However, my question was genuine, based on your observed behavior. I
> agree I might have phrased it more politely, but I do find your
> self-assurance somewhat irritating.
Thanks. :-)
Steven D'Aprano
> You thought you cold do a bit of ad hominem attack.
That phrase you keep using, "ad hominem"... it doesn't mean what you seem
to think it means.
An ad hominem attack is not when somebody makes a criticism of you
personally. It is when somebody says something along the lines of "Don't
pay any attention to Alf, he doesn't know what he's talking about, he's a
<whatever>".
You might not like the personal criticism, but that doesn't make it
either an attack or a fallacy.
--
Steven
Alf P. Steinbach
> On Tue, 09 Feb 2010 21:04:08 +0100, Alf P. Steinbach wrote:
>
>> You thought you cold do a bit of ad hominem attack.
>
> That phrase you keep using, "ad hominem"... it doesn't mean what you seem
> to think it means.
>
> An ad hominem attack is not when somebody makes a criticism of you
> personally. It is when somebody says something along the lines of "Don't
> pay any attention to Alf, he doesn't know what he's talking about, he's a
> <whatever>".
<url: http://www.tfd.com/ad+hominem>
ad hominem Latin [æd ˈhɒmɪˌnɛm]
adj & adv
1. directed against a person rather than against his arguments
2. based on or appealing to emotion rather than reason Compare ad rem See also
argumentum ad hominem
> You might not like the personal criticism, but that doesn't make it
> either an attack or a fallacy.
Steve Holden attacked only at the personal level, via characterization.
In response to ...
> >> No idea. Nothing I know of can solve it [failure of article propagation].
>
> Not sure, but perhaps it's possible to mail directly to gmane?
... Steve Holden wrote:
<quote>
Is there *any* problem you don't have a fatuous answer for?
</quote>
Which doesn't have anything to do with any subject matter discussed, not even
the PS that he was replying to (which absolutely didn't warrant that description
or any negative response), but which does convey an impression of a person.
Then he wrote
<quote>
you assumed you knew better than Stephen [Hansen]
</quote>
which again is only about a person, and here about the person's motivations for
trying to help.
And there was a bit more with some collateral damage in the implications.
It's pretty dirty and yes, personal attacks are ad hominem; see above.
The ad hominem attacks that he appears to routinely engage in reflect back on
Steve Holden but the sub-threads that they invariably spawn also constitute a
high level of noise deflecting from whatever issue was discussed.
Cheers & hth. (especially the dictionary reference),
- Alf
PS: in order to recognize various forms of fallacies the following is a quite
useful resource: <url: http://www.nizkor.org/features/fallacies/>. I just typed
"fallacies" in the Firefox address bar. - DS
Ben Finney
> An ad hominem attack is not when somebody makes a criticism of you
> personally. It is when somebody says something along the lines of
> "Don't pay any attention to Alf, he doesn't know what he's talking
> about, he's a <whatever>".
In other words, a criticism of the person is only a fallacy if it is
both irrelevant to the argument *and* used to dismiss the argument.
Many criticisms are introduced not because they directly connect to the
argument, but simply because they are relevant to the demonstrated
behaviour at the time.
> You might not like the personal criticism, but that doesn't make it
> either an attack or a fallacy.
Exactly. A personal criticism can be expressed *as a criticism*, and be
valid or not without needing to be relevant to your chosen argument.
Look to the criticism on its own merits, and decide what to do about it.
--
\ “If there were not God, there would be no atheists.” —G. K. |
`\ Chesterton |
_o__) |
Ben Finney
Alf P. Steinbach
> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes:
>
>> An ad hominem attack is not when somebody makes a criticism of you
>> personally. It is when somebody says something along the lines of
>> "Don't pay any attention to Alf, he doesn't know what he's talking
>> about, he's a <whatever>".
>
> In other words, a criticism of the person is only a fallacy if it is
> both irrelevant to the argument *and* used to dismiss the argument.
Or to weaken an argument, or to draw attention away from an argument, or to
weaken future arguments...
However, although in this particular case the Ad Hominems constituted logical
fallacies, not all Ad Hominems are logical fallacies.
For example, if a person is a chronic liar, has a known history of lying, then
that can have a strong bearing on whether the person's claims -- technical or
about other persons -- should be seriously considered[1].
Cheers & hth.,
- Alf
Notes:
[1] As explained at <url:
http://www.nizkor.org/features/fallacies/personal-attack.html>
Gabriel Genellina
escribió:
> * Steven D'Aprano:
>> On Tue, 09 Feb 2010 21:04:08 +0100, Alf P. Steinbach wrote:
>>
>>> You thought you cold do a bit of ad hominem attack.
>> That phrase you keep using, "ad hominem"... it doesn't mean what you
>> seem to think it means.
>> An ad hominem attack is not when somebody makes a criticism of you
>> personally. It is when somebody says something along the lines of
>> "Don't pay any attention to Alf, he doesn't know what he's talking
>> about, he's a <whatever>".
>
> <url: http://www.tfd.com/ad+hominem>
> ad hominem Latin [æd ˈhɒmɪˌnɛm]
> adj & adv
> 1. directed against a person rather than against his arguments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2. based on or appealing to emotion rather than reason Compare ad rem
> See also argumentum ad hominem
>
> In response to ...
>
> > >> No idea. Nothing I know of can solve it [failure of article
> propagation].
> >
> > Not sure, but perhaps it's possible to mail directly to gmane?
>
> ... Steve Holden wrote:
>
> <quote>
> Is there *any* problem you don't have a fatuous answer for?
> </quote>
>
> Which doesn't have anything to do with any subject matter discussed, not
> even the PS that he was replying to (which absolutely didn't warrant
> that description or any negative response), but which does convey an
> impression of a person.
This doesn't make it an ad hominem fallacie. This is just criticism
directed to your person, that you may like or not. It would be a fallacie
if it were intended to dismiss your argument.
> PS: in order to recognize various forms of fallacies the following is a
> quite useful resource: <url: http://www.nizkor.org/features/fallacies/>.
> I just typed "fallacies" in the Firefox address bar. - DS
From the above site:
"this fallacy involves two steps. First, an attack against the character
of person making the claim [...] Second, this attack is taken to be
evidence against the claim or argument the person in question is making
(or presenting)."
That second part is missing in S. H. posts.
--
Gabriel Genellina
D'Arcy J.M. Cain
> fallacies, not all Ad Hominems are logical fallacies.
Yes they are. Using the reputation of someone to prove or disprove
their claims is a logical fallacy.
> For example, if a person is a chronic liar, has a known history of lying, then
> that can have a strong bearing on whether the person's claims -- technical or
> about other persons -- should be seriously considered[1].
Yes but it's still a fallacy. Taking the author's history into account
may be valid for deciding that further investigation is warranted but by
itself it does not prove anything about the claims. Suggesting that it
does is fallacious.
"Bill is a liar therefore his statement is false" is a fallacy. "Bill
is a liar so take his claims with a grain of salt" is not.
There is another case. "Bill never tells the truth therefore his
claim is wrong" is not an ad hominem fallacy. It's a sylogism. It may
or may not be correct but if the first statement is true (Bill always
lies) then the the conclusion is true.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Steven Howe
to get a room and start discussing angel counts on pinheads under the
blankets.
sph
On 02/09/2010 10:51 PM, D'Arcy J.M. Cain wrote:
> On Wed, 10 Feb 2010 01:38:50 +0100
> "Alf P. Steinbach"<al...@start.no> wrote:
>
>> However, although in this particular case the Ad Hominems constituted logical
>> fallacies, not all Ad Hominems are logical fallacies.
>>
> Yes they are. Using the reputation of someone to prove or disprove
> their claims is a logical fallacy.
>
>
>> For example, if a person is a chronic liar, has a known history of lying, then
>> that can have a strong bearing on whether the person's claims -- technical or
>> about other persons -- should be seriously considered[1].
>>
Ben Finney
> On Wed, 10 Feb 2010 01:38:50 +0100
> "Alf P. Steinbach" <al...@start.no> wrote:
> > However, although in this particular case the Ad Hominems
> > constituted logical fallacies, not all Ad Hominems are logical
> > fallacies.
>
> Yes they are. Using the reputation of someone to prove or disprove
> their claims is a logical fallacy.
The trouble is, the bulk of statements Alf is calling “ad hominem
attack” are, if one actually reads them, a criticism of his person. Not
intended as a connecting claim in an argument, but a claim *distinct
from* the argument Alf is engaged in.
So they're *not intended* to prove or disprove the specific claims that
immediately precede them. They're intended, at least partly, to provoke
self-reflection on the part of the person criticised and, ideally, an
improvement in behaviour.
Failure to recognise a criticism as such, and instead repeatedly
flinging the term “ad hominem” around as though it has any bearing, is
an example of behaviour that could easily be improved, if only the
person engaging in it would stop.
--
\ “You've got to think about big things while you're doing small |
`\ things, so that all the small things go in the right |
_o__) direction.” —Alvin Toffler |
Ben Finney
Alf P. Steinbach
> "D'Arcy J.M. Cain" <da...@druid.net> writes:
>
>> On Wed, 10 Feb 2010 01:38:50 +0100
>> "Alf P. Steinbach" <al...@start.no> wrote:
>>> However, although in this particular case the Ad Hominems
>>> constituted logical fallacies, not all Ad Hominems are logical
>>> fallacies.
>> Yes they are. Using the reputation of someone to prove or disprove
>> their claims is a logical fallacy.
>
> The trouble is, the bulk of statements Alf is calling “ad hominem
> attack” are, if one actually reads them, a criticism of his person. Not
> intended as a connecting claim in an argument, but a claim *distinct
> from* the argument Alf is engaged in.
That's false. Happily anyone can check back, e.g. up-thread here.
Judging by the last few months the number of persons engaging in ad hominem
attacks in this group is small, counted on one hand with possibly one finger
from the other hand to help. They're very active. But happily, few.
However, in the other non-moderated groups I participate in the number of such
persons is essentially *zero*, not counting sporadic visits from trolls.
> So they're *not intended* to prove or disprove the specific claims that
> immediately precede them. They're intended, at least partly, to provoke
> self-reflection on the part of the person criticised and, ideally, an
> improvement in behaviour.
And that's ad hominem, implying unacceptable behavior on my part, which if you
could back up you'd cited.
> Failure to recognise a criticism as such, and instead repeatedly
> flinging the term “ad hominem” around as though it has any bearing, is
> an example of behaviour that could easily be improved, if only the
> person engaging in it would stop.
Alf P. Steinbach
>
> 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,
>
>
>
> 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.
Duncan Booth
>> 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
Steven D'Aprano
>> 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
Robert Kern
> Really, is this a relevant topic on a program mail list?
Yes. Meta-discussions about how we discuss programming productively are also
on-topic.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Alf P. Steinbach
> "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.
Alf P. Steinbach
> 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.
Ethan Furman
>
> 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~
Steve Holden
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.
Steven D'Aprano
> "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
Alf P. Steinbach
> Alf P. Steinbach wrote:
>>
>> 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.
>>
>>
>> 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.
Alf P. Steinbach
> 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.
John Posner
>
> 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
Arnaud Delobelle
[...]
> 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
Alf P. Steinbach
> 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, by a concrete example.
Summing up, denying the existence of references, as you do at the top, is just
silly; do consider the code example.
Your points 1, 3 and 4 attack positions that I do not hold and have not advocated.
Your point 2, about terminology, is important on its own. And I suggest you
check out the references I've given. And read what I quoted from the language
specification of a language with the same semantics as Python.
Steven D'Aprano
> 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
Alf P. Steinbach
> 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.
Steve Holden
> * 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.
>
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.
>
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.
Alf P. Steinbach
>
> 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
Steve Holden
> * 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.
>
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".
Steve Holden
> * 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.
>
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.
Steve Holden
> 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?
>
>
>
> 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.
Alf P. Steinbach
> 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
> 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.
Yes.
>> 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.
Oh, good. :-)
>>> 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.
On the contrary, the closest abstraction to reference semantics is reference
semantics.
No special cases needed.
No extraneous conceptual ballast.
> I don't think it's unreasonable to describe that as
> "hand-waving". You apparently do.
Yes and no.
Regarding what you write now, that is regarding what people (who don't have set
positions) find easier to grasp: discussing that is necessarily handwaiving, but
to the same degree no matter which side you argue. Unless one applies
statistics. So by your own argument you're handwaiving.
On the other hand, regarding what you wrote earlier you implied a history of
handwaiving from me.
You would be unable to give examples of that.
But above you present an argument about IronPython which suggest some
unspecified contradiction with something unspecified (to get to the implied
contradiction a reader would have to form a picture that would be
misrepresenting me), and *that* is an example of handwaiving, diversion and
misrepresentation -- which I didn't have to look far to find...
>> 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.
What on Earth are you babbling about now? I say what I do. You therefore think
I'm reading your mind? Hello. Get a grip.
>> 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,
Denial is just stupid, sorry.
> it uniquely represents an *object*.
Yes, and that implies that it also uniquely represents a pointer to the object.
If nothing else you could take the address of the object and have a direct
correspondence (one-to-one mapping) with the id value, contradicting your
statement. But that's just one concrete example, it doesn't capture the general
idea of an abstract pointer: it only shows that your statement is a
self-contradiction, i.e., fallacious.
>> 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".
Yes, you have point there (the first so far, I must add, since this is at the
end of the article!). And it is a good but subtle point that I was a bit
hesitant to mention. But since you've let that cat out of ze bag, Java and
Python differ in what dangerous name/pointer features they offer: IIRC Java
allows a name to become "unbound" by assigning nullpointer, i.e. an extra path
to that dangerous nullpointer/unbound state, while Python allows a name to
become non-existent via del, i.e. an extra path to that dangerous non-existence.
Still, the unbound/nullpointer state is the same, with the same effect.
And that's quite suggestive.
Dino Viehland
> 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 0x000000000000002B>
>>> 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.
Alf P. Steinbach
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
Steven D'Aprano
> * 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
alex23
> 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?
Alf P. Steinbach
> 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."
>
> 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.
Well, apart from... As you say.
> 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.
Yes, that's right.
It does not mean that such a description is invalid.
It only means that common sense needs to be applied, and that the urge to
misinterpret needs to be suppressed. I don't think those are problems for
novices. But still a better term than "pointer" would be nice, and I guess
"reference" is it, as suggested by the course material I linked to.
Alf P. Steinbach
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
I V
> * Steven D'Aprano:
>> 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.
Alf P. Steinbach
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)
Steve Holden
> * 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.
>
message <hgbri8$e17$1...@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.
Steve Holden
> * Steven D'Aprano:
>> accusing them of lying for having an opinion that differs from yours,
>
> That is untrue.
>
Alf P. Steinbach
> 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
Alf P. Steinbach
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]
Terry Reedy
> 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
Alf P. Steinbach
> 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.
Martin P. Hellwig
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
Steven D'Aprano
> 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
Steven D'Aprano
>> 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
Alf P. Steinbach
Good joke. :-)
Cheers,
- Alf