Modifying Class Object

[Steve Holden]

* Steve Holden:

* Michael Sparks:
[Due to the appearance of reasoned discussion (it's not practical to
read it all!) [...]
Therefore to say "in reality the implementation will be passing a
reference or pointer" is invalid. There is after all at least one
implementation that does not rely on such machine oriented language
details.
I'm sorry, but see above: in itself it's just yet another a fallacy.

And as an argument in a debate with me it's misrepresenting.

I see we are still all out of step with you.

Why did you snip the short argument?

Because it's irrelevant and fallacious.

Oh, you snipped it so that you didn't have to present it to readers.

That's dishonest, Steve Holden.

Requoting:



At this point consider whether it's possible to implement Pascal in
Haskell.

If it is possible, then you have a problem wrt. drawing conclusions
about pointers in Pascal, uh oh, they apparently can't exist.

But if it is not possible to implement Pascal in Haskell, then Haskell
must be some etremely limited special-purpose language, not Turing
complete -- is that acceptable to you?
<quote>

This, if it says anything at all, appears to say that any
Turing-complete language has pointers in it, which is an absurdity.

That's meaningless.

But then so is maintaining that Python doesn't have references.

And so is your argument applied to Pascal, just to mention that again.

*You* brought Pascal into this, not me.

On top of the multiple fallacies, dubious snipping of arguments,
statements that such arguments have not been presented (just after
snipping them), and general misleading insinuations and
misrepresentation, ad yet another bit of personal attack.

Do you understand what that may say to readers about you, Steve Holden?

I'm happy to let readers draw their own conclusions about us both.

Apparently it's all to defend an indefensible, idiotic position. But I
think you're doing it at least partially for the fun of harassing someone.

Not at all. You have accused me of bullying behavior, but in truth you
are the bully, and we know what happens when you give in to bullies,
don't we?

[...]

I sincerely hope that my reply does not offend or inflame you, since
that is not the intent. I do hope it educates you and puts
into context the responses you have gained from others.

After all, one simply shouting in a corner saying "YOU'RE ALL
WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT", when one does not to
understand what one is talking about does not tend to engender warm
fluffy feelings or sentiments of authority towards such an
individual. Be it me, you, or anyone else.

At the moment, you appear to me to be engaging in such a behaviour.
Now you don't know from Jack and probably don't care about my
viewpoint, but I would really appreciate it if you would try not to
be inflammatory in your response to this. (Since you do appear to
also have a need to have the last word)

Hoping this was useful on some level,
Yes.

I elected to respond to just /one/ of the many arguments you
presented.

The other arguments, about why there are no references in Python,
shared, however, the basic property of being logical fallacies
packaged in kilometers of rambling text.

And you can say this without, by your own admission, even reading it.

No, you can not quote any place I have said that I haven't read his
article. I did read most of it. So you are yet again within the span of
one posted article presenting untrue information that you know is not true.

I repeat the quote from you which you can read at the top of this post:

[Due to the appearance of reasoned discussion (it's not practical to
read it all!)

[...]

So now you say you read "most" of it. Even this statement is an
admission that there are parts you did not, and yet somehow *I* am the
liar? We are moving from the bizarre to the delusional here.

Gosh, I don't know. You must be stupid to do that. Yes?
Apparently.

That is untrue, Steve Holden, and since you can't quote that "evidence",
since you evidently /have/ read my short article which you're responding
to, knowing exactly what to snip, you know that what you're saying is
untrue. I think this is your third lie in one posting. But who would
care to count.
Who indeed?

Cheers & hth.,

That signature surely has to be irony.

Steve

 

[MRAB]

* Steve Howell:

I think that regarding the technical it is whether a Python name refers
to an object or not. I maintain that it does, and that the reference can
be copied, and that the semantics of the language requires this and is
defined in terms of this. Steve Holden, D'Aprano and many others
maintain that there are no references, or that if there are then they're
only an implementation aspect, i.e. that conceiveable one could have an
implementation without them.

Regarding some other issues it seems to be a childish exercise in
flaming, a flame war, with claims of insanity, incompetence, lying
(that's actually from me, I reacted a bit strongly to faked quoting +
conclusions from that in a posting not appearing on Usenet but on the
Python mail list), etc. etc. ad nauseam, sprinkled with
misrepresentations etc. I don't know the point of that.

It's a pity that no-one has gone far enough to trigger Godwin's Law...
;-)

 

[Alf P. Steinbach]

* Steve Holden:

* Steve Holden:

Alf P. Steinbach wrote:
* Michael Sparks:
[Due to the appearance of reasoned discussion (it's not practical to
read it all!)
[...]
Therefore to say "in reality the implementation will be passing a
reference or pointer" is invalid. There is after all at least one
implementation that does not rely on such machine oriented language
details.
I'm sorry, but see above: in itself it's just yet another a fallacy.

And as an argument in a debate with me it's misrepresenting.

I see we are still all out of step with you.

Why did you snip the short argument?

Because it's irrelevant and fallacious.

Oh, you snipped it so that you didn't have to present it to readers.

That's dishonest, Steve Holden.

Requoting:


At this point consider whether it's possible to implement Pascal in
Haskell.

If it is possible, then you have a problem wrt. drawing conclusions
about pointers in Pascal, uh oh, they apparently can't exist.

But if it is not possible to implement Pascal in Haskell, then Haskell
must be some etremely limited special-purpose language, not Turing
complete -- is that acceptable to you?
<quote>

This, if it says anything at all, appears to say that any
Turing-complete language has pointers in it, which is an absurdity.

That's meaningless.

But then so is maintaining that Python doesn't have references.

And so is your argument applied to Pascal, just to mention that again.

*You* brought Pascal into this, not me.

Of course. And so? Do you think that the/your argument applies to Pascal?

Just for your information, it does not work for Pascal.

Or any language. It is a fallacy. It does not say anything about Python, or
Pascal, or any language.

I'm happy to let readers draw their own conclusions about us both.

I guess you are. For it is invariably so that most readers recall by
association, and a flood of flaming does yield an impression. As a technical
argument it's a fallacy, but do you care? No.

Not at all. You have accused me of bullying behavior, but in truth you
are the bully, and we know what happens when you give in to bullies,
don't we?

After an uncountable number of flames of my person, many from you, I'm the
bullied, or victim, so to speak; as such I'm not the bully.

[...]
I sincerely hope that my reply does not offend or inflame you, since
that is not the intent. I do hope it educates you and puts
into context the responses you have gained from others.

After all, one simply shouting in a corner saying "YOU'RE ALL
WRONG, WRONG, WRONG. I'M RIGHT RIGHT RIGHT", when one does not to
understand what one is talking about does not tend to engender warm
fluffy feelings or sentiments of authority towards such an
individual. Be it me, you, or anyone else.

At the moment, you appear to me to be engaging in such a behaviour.
Now you don't know from Jack and probably don't care about my
viewpoint, but I would really appreciate it if you would try not to
be inflammatory in your response to this. (Since you do appear to
also have a need to have the last word)

Hoping this was useful on some level,
Yes.

I elected to respond to just /one/ of the many arguments you
presented.

The other arguments, about why there are no references in Python,
shared, however, the basic property of being logical fallacies
packaged in kilometers of rambling text.

And you can say this without, by your own admission, even reading it.

No, you can not quote any place I have said that I haven't read his
article. I did read most of it. So you are yet again within the span of
one posted article presenting untrue information that you know is not true.

I repeat the quote from you which you can read at the top of this post:

[Due to the appearance of reasoned discussion (it's not practical to
read it all!)
[...]

So now you say you read "most" of it.

I haven't said anything contradictory about that. If I had then you'd have
quoted it. You don't quote anything, so you're out on your usual
insinuate-things argumentation technique.

Even this statement is an
admission that there are parts you did not, and yet somehow *I* am the
liar? We are moving from the bizarre to the delusional here.

I'm sorry that I had to point out your relating untrue information that you knew
at the time was untrue.

That also applies to your snipping of the argument about Haskell, and subsequent
asking for such arguments as if they hadn't been given -- and snipped.

The poster explained at the start that he had some technically immaterial stuff
at the end of his article. I don't know whether I reached that. But anyway, the
article was just a series of fallacies like the one thinking an implementation
in Haskell could prove anything about the language so implemented, all wrapped
up in kilometers of rambling text.

Your attack of "bizarre" and "delusion" are the usual from Steve Holden.

You are injecting noise to bury an argument that you didn't like. You tried
first snipping it from your response. Now you're trying the noise angle again.


Cheers & hth.,

- Alf

 

[Aahz]

My original statement, with reference to the Java language spec,
didn't say much more about the language than that it has assignable
references.

Assuming this is what you're referring to:

Python passes pointers by value, just as e.g. Java does.

Then you are simply, completely, totally, and absolutely wrong. Period.
Regardless of how CPython manages its state internally, Python as a
programming language does not have pointers.

 

[Steve Howell]

Assuming this is what you're referring to:

    Python passes pointers by value, just as e.g. Java does.

Then you are simply, completely, totally, and absolutely wrong.  Period..
Regardless of how CPython manages its state internally, Python as a
programming language does not have pointers.  

I agree with your statement for a suitably narrow definition of the
words "pointer" and "have."

 

[Steve Howell]

It's a pity that no-one has gone far enough to trigger Godwin's Law...
;-)

Godwin's Law need not be invoked here. The essential question is
relevant and worthy of discussion, and most posters have presented
intelligent, nuanced arguments even amidst all the needless flaming.
It is actually a subtle point that I think people disagree on,
whatever the extraneous personal baggage.

 

[Alf P. Steinbach]

* Aahz:

Assuming this is what you're referring to:

Python passes pointers by value, just as e.g. Java does.

Then you are simply, completely, totally, and absolutely wrong. Period.
Regardless of how CPython manages its state internally, Python as a
programming language does not have pointers.

The next paragraph was about the meaning of "pointer" in that first paragraph,
referring to the Java language specification for the particular meaning here,
namely a reference. Note: I did not refer to CPython, C, Pascal or whatever (but
you mention CPython) for a meaning of "pointer". Instead I referred to the Java
language specification for that meaning, where it's pretty clear: reference.

So if you don't like the terminology, you can rephrase with perhaps more
palatable terms:

Python uses pass by sharing.
References to objects are copied, the objects themselves are not copied.
See <url: http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing>

If you go to that URL, which isn't auhoritative but good enough, you find that

"identical semantics in other languages such as Java and Visual Basic"

Hence, your point is only a matter of terminology. The semantics /can/ be
described using the term "pointer" (or for that matter the term "thingamajic"),
when that term is suitably defined, and it /is/ described using that word for
some languages. The language doesn't matter for the concept of pass by sharing.

Hence, the terminological issue doesn't invalidate the description, as long as
the terminology is clearly defined, as I did with ref to the Java lang spec.

As you can see proper terminology reduces the size of explanation considerably,
but as I see it that's not a big deal as long as the description is still
/reasonably/ short. It does become a concern when the description runs to many
pages of text. A simple thing should IMHO be simply described.

But I think, as I've already stated several times up-thread, that "pointer" is a
term best avoided for explanations within the Python community, even with a
reference to a particular definition/usage, making the more verbose version in
terms of "references" preferable for Python -- don't you agree?


Cheers,

- Alf

 

[Steven D'Aprano]

On Feb 13, 6:41 pm, (e-mail address removed) (Aahz) wrote:

I agree with your statement for a suitably narrow definition of the
words "pointer" and "have."

"Suitably narrow" is not that narrow. By no stretch of the imagination
can one say that Python has a built-in pointer type analogous to pointers
in (say) Pascal or C -- you can't usefully get the address of a variable
(although the CPython implementation leaks the address of objects, it
does so in a way that is safe and useless for everything but a label).
There is no equivalent to (say) the Pascal program:

program main(input, output);
var
x: integer;
ptr: ^integer;

begin
x := 1;
ptr := @x;
ptr^ := ptr^ + 1;
writeln(x);
end.

For a suitably wide definition of "pointer", then Python does have
pointers:

data = ['aaa', 'bbb', 'ccc', 'ddd', 'eee']
i = data.index('bbb')
print data
i += 1
data = 'zzz'


but I trust that we all agree that describing the integer offset i above
as a "pointer" is a reductio ad absurdum.

 

[Steve Howell]

I agree with your statement for a suitably narrow definition of the
words "pointer" and "have."

"Suitably narrow" is not that narrow. By no stretch of the imagination
can one say that Python has a built-in pointer type analogous to pointers
in (say) Pascal or C -- you can't usefully get the address of a variable
(although the CPython implementation leaks the address of objects, it
does so in a way that is safe and useless for everything but a label).
There is no equivalent to (say) the Pascal program:

program main(input, output);
  var
    x: integer;
    ptr: ^integer;

begin
  x := 1;
  ptr := @x;
  ptr^ := ptr^ + 1;
  writeln(x);
end.

For a suitably wide definition of "pointer", then Python does have
pointers:

data = ['aaa', 'bbb', 'ccc', 'ddd', 'eee']
i = data.index('bbb')
print data
i += 1
data = 'zzz'

but I trust that we all agree that describing the integer offset i above
as a "pointer" is a reductio ad absurdum.

For a suitably wide definition of pointers CPython does indeed have
pointers, and your example is only a weaker case of that truth. There
is no reductio adsurbum. If I argued that CPython had curly braced
syntax that would be absurd, since it is so concretely wrong.
Pointers are a more abstact concept.

 

[Steven D'Aprano]

For a suitably wide definition of pointers CPython does indeed have
pointers, and your example is only a weaker case of that truth. There
is no reductio adsurbum. If I argued that CPython had curly braced
syntax that would be absurd, since it is so concretely wrong. Pointers
are a more abstact concept.

I would argue that your examples are equivalent.

The suitably wide definition of pointers that allows you to argue that
Python has pointers is an implementation detail, just as the
implementation detail that the Python tokenizer uses INDENT and DEDENT
tokens. An INDENT token is just another way of spelling { and DEDENT is
just another way of spelling }, so therefore Python has curly bracket
syntax.

Do I believe this argument is valid? No, of course not, I think it does
so much violence to the concepts of curly brackets and syntax as to be
absurd. Just as I think the only way to justify claiming that Python has
pointers is to do so much violence to the concept of pointer and to
Python's object model as to also be absurd.

That's not to say that the general concept of references (as in "to refer
to") isn't valuable when discussing Python. If you want to say that
(e.g.) following

x = 1

the name "x" refers to (or even points to!) the object 1, my objections
will be mild or non-existent. In that sense, it's probably impossible to
program without some sort of "references": the computer manipulates
variables or objects directly, while we manipulate characters in source
code. The only way to write a program is to use some abstract thing (a
name, an offset, whatever) that refers, in some fashion, to a collection
of bits in the computer's memory. But to go from that to the idea that
(say) x is a pointer does so much violence to the concept of pointer and
has so much room for confusion that it is actively harmful.

 

[Steve Howell]

I would argue that your examples are equivalent.

The suitably wide definition of pointers that allows you to argue that
Python has pointers is an implementation detail, just as the
implementation detail that the Python tokenizer uses INDENT and DEDENT
tokens. An INDENT token is just another way of spelling { and DEDENT is
just another way of spelling }, so therefore Python has curly bracket
syntax.

You seem to be missing the point that "curly braces" is a concrete
term that very specifically applies to spelling.

Do I believe this argument is valid? No, of course not, I think it does
so much violence to the concepts of curly brackets and syntax as to be
absurd. Just as I think the only way to justify claiming that Python has
pointers is to do so much violence to the concept of pointer and to
Python's object model as to also be absurd.

That's not to say that the general concept of references (as in "to refer
to") isn't valuable when discussing Python. If you want to say that
(e.g.) following

x = 1

the name "x" refers to (or even points to!) the object 1, my objections
will be mild or non-existent. In that sense, it's probably impossible to
program without some sort of "references": the computer manipulates
variables or objects directly, while we manipulate characters in source
code. The only way to write a program is to use some abstract thing (a
name, an offset, whatever) that refers, in some fashion, to a collection
of bits in the computer's memory. But to go from that to the idea that
(say) x is a pointer does so much violence to the concept of pointer and
has so much room for confusion that it is actively harmful.

I agree that "reference" is a much better term than "pointer.". It has
the right amount of generalness in my opinion. I think "violence" is a
bit overstated, but your bigger point is well taken and it seems like
"reference" is useful middle ground between pure cpython language and
misrepresentative analogy.

 

[Steven D'Aprano]

You seem to be missing the point that "curly braces" is a concrete
term that very specifically applies to spelling.

And you seem to be missing the point that "pointer" is also a concrete
term that very specifically applies to, well, pointers.

[...]

I agree that "reference" is a much better term than "pointer.". It has
the right amount of generalness in my opinion. I think "violence" is a
bit overstated, but your bigger point is well taken and it seems like
"reference" is useful middle ground between pure cpython language and
misrepresentative analogy.

But reference also has a concrete meaning: C++ has a type explicitly
called "reference":

http://en.wikipedia.org/wiki/Reference_(C++)

And of course call-by-reference (or pass-by-reference) has a specific,
technical meaning.

 

[Alf P. Steinbach]

* Steven D'Aprano:

You seem to be missing the point that "curly braces" is a concrete
term that very specifically applies to spelling.

And you seem to be missing the point that "pointer" is also a concrete
term that very specifically applies to, well, pointers.

[...]

I agree that "reference" is a much better term than "pointer.". It has
the right amount of generalness in my opinion. I think "violence" is a
bit overstated, but your bigger point is well taken and it seems like
"reference" is useful middle ground between pure cpython language and
misrepresentative analogy.

But reference also has a concrete meaning: C++ has a type explicitly
called "reference":

http://en.wikipedia.org/wiki/Reference_(C++)

And of course call-by-reference (or pass-by-reference) has a specific,
technical meaning.

Hm.

Consider your argument about "reference" being possible to confuse with "pass by
reference" in the light of "pass by name", used by Algol, <url:
http://en.wikipedia.org/wiki/Jensen's_Device>.

Oops, to consistently remove all possible ambiguity the term "name" can't be
used about formal arguments.

I think, even though "pass by name" is much less well known than "pass by
reference", this indicates that it's not practically possible to remove all
possible ambiguity.

I think some Common Sense(TM) must in any case be assumed, and applied.


Cheers,

- Alf

 

[Steve Howell]

And you seem to be missing the point that "pointer" is also a concrete
term that very specifically applies to, well, pointers.

The term "pointer" is very abstract. Please give me a concrete
definition of a pointer.

A curly brace is one of these: { }

Pretty concrete, I hope.

[...]

I agree that "reference" is a much better term than "pointer.". It has
the right amount of generalness in my opinion. I think "violence" is a
bit overstated, but your bigger point is well taken and it seems like
"reference" is useful middle ground between pure cpython language and
misrepresentative analogy.

But reference also has a concrete meaning: C++ has a type explicitly
called "reference":

http://en.wikipedia.org/wiki/Reference_(C++)

Of course, "reference" has concrete meanings in specific contexts.
But I can refer you to much more general and abstract uses of the term
"reference." Do you want references? I will be happy to refer you
to appropriate references.

And of course call-by-reference (or pass-by-reference) has a specific,
technical meaning.

Which is what?

 

[Steve Howell]

Alf, although your English in this forum has been excellent so far, I
understand you are Norwegian, so it is possible that you aren't a native
English speaker and possibly unaware that quotation marks are sometimes
ambiguous in English.

While it is true that quoted text is officially meant to indicate a
direct quote, it is also commonly used in informal text to indicate a
paraphrase. (There are other uses as well, but they don't concern us now.)

Unfortunately, this means that in informal discussions like this it is
sometimes difficult to distinguish a direct quote from a paraphrase,
except by context. In context, as a native speaker, I can assure you that
Stephen Hansen's use of quotation marks is a paraphrase and not meant to
be read as a direct quote.

As another native speaker of English, I can assure Alf that using
quotation marks in a paraphrase in written English is actually
strictly admonished against in some English speaking countries. At
least according to my English teachers. To the extent that many
people on the Internet don't speak English natively, I think the most
conservative and reasonable convention applies--use quotes to quote
directly; if you're not quoting directly, omit quotes and make clear
the fact that you are paraphrasing.

Which isn't to say we don't all make mistakes.

I have no idea about what Stephen Hanson said. Most misattributions
are actually paraphrases, whether they be in quotes or not.

 

[Steven D'Aprano]

The term "pointer" is very abstract. Please give me a concrete
definition of a pointer.

A programming language data type whose value directly specifies (or
"points to") another value which is stored elsewhere in the computer
memory.

I quote from Wikipedia:

http://en.wikipedia.org/wiki/Pointer_(computing)

A pointer is a simple, less abstracted implementation of the
more abstracted reference data type
[end quote]

And later:

While "pointer" has been used to refer to references in
general, it more properly applies to data structures whose
interface explicitly allows the pointer to be manipulated
(arithmetically via pointer arithmetic) as a memory
address...
[end quote]

And again:

A memory pointer (or just pointer) is a primitive, the value
of which is intended to be used as a memory address; it is said
that a pointer points to a memory address. It is also said that
a pointer points to a datum [in memory] when the pointer's value
is the datum's memory address.

More generally, a pointer is a kind of reference, and it is said
that a pointer references a datum stored somewhere in memory; to
obtain that datum is to dereference the pointer. The feature that
separates pointers from other kinds of reference is that a
pointer's value is meant to be interpreted as a memory address,
which is a rather 'low-level' concept.
[end quote]

A curly brace is one of these: { }

Pretty concrete, I hope.

But { and } are glyphs in some typeface. Chances are that what you see,
and what I see, are quite different, and whatever pixels we see, the
compiler sees something radically different: two abstract characters
implemented in some concrete fashion, but that concrete fashion is a mere
implementation detail. They could be implemented as bytes x7b and x7d, or
as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows
what in some other system. So the *concrete* representation of the curly
brace varies according to the system.

From that, it's not a difficult leap to say that Pascal's BEGIN and END
key words are mere alternate spellings of the abstract "open curly brace"
and "close curly brace" with different concrete representations, and from
that it's a small step to say that the INDENT and DEDENT tokens seen by
the Python compiler (but absent from Python source code!) are too.

Of course, "reference" has concrete meanings in specific contexts. But I
can refer you to much more general and abstract uses of the term
"reference." Do you want references? I will be happy to refer you to
appropriate references.

I know that reference can also be used in the abstract. I'm just warning
that it can also be used in the concrete, and so we need to be wary of
misunderstandings and confusions.

Which is what?

http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

 

[Steve Howell]

The term "pointer" is very abstract.  Please give me a concrete
definition of a pointer.

A programming language data type whose value directly specifies (or
"points to") another value which is stored elsewhere in the computer
memory.

I quote from Wikipedia:

http://en.wikipedia.org/wiki/Pointer_(computing)

   

    A pointer is a simple, less abstracted implementation of the
    more abstracted reference data type
    [end quote]

And later:

   

    While "pointer" has been used to refer to references in
    general, it more properly applies to data structures whose
    interface explicitly allows the pointer to be manipulated
    (arithmetically via pointer arithmetic) as a memory
    address...
    [end quote]

And again:

   

    A memory pointer (or just pointer) is a primitive, the value
    of which is intended to be used as a memory address; it is said
    that a pointer points to a memory address. It is also said that
    a pointer points to a datum [in memory] when the pointer's value
    is the datum's memory address.

    More generally, a pointer is a kind of reference, and it is said
    that a pointer references a datum stored somewhere in memory; to
    obtain that datum is to dereference the pointer. The feature that
    separates pointers from other kinds of reference is that a
    pointer's value is meant to be interpreted as a memory address,
    which is a rather 'low-level' concept.
    [end quote]

A curly brace is one of these: { }

Pretty concrete, I hope.

But { and } are glyphs in some typeface. Chances are that what you see,
and what I see, are quite different, and whatever pixels we see, the
compiler sees something radically different: two abstract characters
implemented in some concrete fashion, but that concrete fashion is a mere
implementation detail. They could be implemented as bytes x7b and x7d, or
as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows
what in some other system. So the *concrete* representation of the curly
brace varies according to the system.

From that, it's not a difficult leap to say that Pascal's BEGIN and END
key words are mere alternate spellings of the abstract "open curly brace"
and "close curly brace" with different concrete representations, and from
that it's a small step to say that the INDENT and DEDENT tokens seen by
the Python compiler (but absent from Python source code!) are too.

Thanks. It's a useful analogy; I think I understand your point
better. I've been bouncing around between Python and Javascript a lot
lately, so your analogy resonates with me. There are many times when
I find myself simply respelling things like begin/end, and those
respellings to me almost make me think of Python and Javascript as
different dialects of an underlying language. Of course, there are
other places where the languages differ more substantively, too.

Going back to pointers vs. references, I think the key distinction
being made is that pointers allow specific memory manipulation,
although I think even there you're really just dealing with
abstractions. The address 0x78F394D2 is a little bit closer to the
machine than, say, the 42nd element of a Python list, but they are
both just abstractions on top of underlying machines, whether the
machines are virtual, electronic circuits, vacuum tubes, whatever.
You can add 6 to 42 and get the 48th object, but its Python's
convention not to call the 48th object a memory address or expose a
reference to it as a pointer. If I want to pass along the reference
to the 48th element of a list as the slot to be updated (i.e. with the
intention to actually mutate the list itself), then I need a tuple
like (lst, 48).

 

[Dennis Lee Bieber]

On Sun, 14 Feb 2010 00:50:04 -0800, Stephen Hansen
<[email protected]> declaimed the following in
gmane.comp.python.general:

<snipping all actual content>

Hodges' Harbrace College Handbook 10th Ed.

16a Use quotation marks for direct quotations. ...
16b Use quotation marks for minor titles (short stories, ...

16c Words used in a special or an ironic sense are sometimes
enclosed in quotation marks

{We'll skip "e" and "f" which tend to cover overuse and other
punctuation with the quotes -- as "American" usage of punctuation
adjacent to quotes is pretty much at total odds with syntax of
programming languages <G>}

 

[Ethan Furman]

The term "pointer" is very abstract. Please give me a concrete
definition of a pointer.

A programming language data type whose value directly specifies (or
"points to") another value which is stored elsewhere in the computer
memory.

I quote from Wikipedia:

http://en.wikipedia.org/wiki/Pointer_(computing)

A pointer is a simple, less abstracted implementation of the
more abstracted reference data type
[end quote]

And later:

While "pointer" has been used to refer to references in
general, it more properly applies to data structures whose
interface explicitly allows the pointer to be manipulated
(arithmetically via pointer arithmetic) as a memory
address...
[end quote]

And again:

A memory pointer (or just pointer) is a primitive, the value
of which is intended to be used as a memory address; it is said
that a pointer points to a memory address. It is also said that
a pointer points to a datum [in memory] when the pointer's value
is the datum's memory address.

More generally, a pointer is a kind of reference, and it is said
that a pointer references a datum stored somewhere in memory; to
obtain that datum is to dereference the pointer. The feature that
separates pointers from other kinds of reference is that a
pointer's value is meant to be interpreted as a memory address,
which is a rather 'low-level' concept.
[end quote]

A curly brace is one of these: { }

Pretty concrete, I hope.

But { and } are glyphs in some typeface. Chances are that what you see,
and what I see, are quite different, and whatever pixels we see, the
compiler sees something radically different: two abstract characters
implemented in some concrete fashion, but that concrete fashion is a mere
implementation detail. They could be implemented as bytes x7b and x7d, or
as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows
what in some other system. So the *concrete* representation of the curly
brace varies according to the system.

From that, it's not a difficult leap to say that Pascal's BEGIN and END
key words are mere alternate spellings of the abstract "open curly brace"
and "close curly brace" with different concrete representations, and from
that it's a small step to say that the INDENT and DEDENT tokens seen by
the Python compiler (but absent from Python source code!) are too.

Thanks. It's a useful analogy; I think I understand your point
better. I've been bouncing around between Python and Javascript a lot
lately, so your analogy resonates with me. There are many times when
I find myself simply respelling things like begin/end, and those
respellings to me almost make me think of Python and Javascript as
different dialects of an underlying language. Of course, there are
other places where the languages differ more substantively, too.

Going back to pointers vs. references, I think the key distinction
being made is that pointers allow specific memory manipulation,
although I think even there you're really just dealing with
abstractions. The address 0x78F394D2 is a little bit closer to the
machine than, say, the 42nd element of a Python list, but they are
both just abstractions on top of underlying machines, whether the
machines are virtual, electronic circuits, vacuum tubes, whatever.
You can add 6 to 42 and get the 48th object, but its Python's
convention not to call the 48th object a memory address or expose a
reference to it as a pointer. If I want to pass along the reference
to the 48th element of a list as the slot to be updated (i.e. with the
intention to actually mutate the list itself), then I need a tuple
like (lst, 48).

I think that's the key right there -- if 48 was really a pointer, you
wouldn't need to pass lst in as 48 would in fact be the memory address
of the object you wanted to manipulate.

~Ethan~

 

[Alf P. Steinbach]

* Ethan Furman:

I think that's the key right there -- if 48 was really a pointer, you
wouldn't need to pass lst in as 48 would in fact be the memory address
of the object you wanted to manipulate.

The generalization is known as a "based pointer".

Except where it's a fundamental abstraction in a programming language, where it
might be called anything.

For example, in C++ some so called "member pointers" are logically based
pointers. They have pointer syntax (as do C++ iterators, which are not
necessarily pointers), but member pointers are not pointers in the C++
standard's sense; in particular, dereferencing a C++ member pointer yields a
typeless entity, which is not the case for a normal pointer, although that
standard confusingly calls also member pointers pointers in some places, and in
other places uses the pointer term only about basic pointers.

So, delving into the details of that terminology means traveling into a pretty
chaotic territory. But on the other hand, going for the more abstract it gets
cleaner and simpler. The Wikipedia article is about in the middle somewhere.

It is perhaps not confusing that it is confusing to many.


Cheers & hth.,

- Alf