Modifying Class Object

[Steve Howell]

On Feb 13, 9:13 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 13 Feb 2010 20:11:06 -0800, Steve Howell wrote:
> > For a suitably wide definition of pointers CPython does indeed have
> > pointers, and your example is only a weaker case of that truth.  There
> > is no reductio adsurbum.  If I argued that CPython had curly braced
> > syntax that would be absurd, since it is so concretely wrong. Pointers
> > are a more abstact concept.
>
> I would argue that your examples are equivalent.
>
> The suitably wide definition of pointers that allows you to argue that
> Python has pointers is an implementation detail, just as the
> implementation detail that the Python tokenizer uses INDENT and DEDENT
> tokens. An INDENT token is just another way of spelling { and DEDENT is
> just another way of spelling }, so therefore Python has curly bracket
> syntax.
>

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


> Do I believe this argument is valid? No, of course not, I think it does
> so much violence to the concepts of curly brackets and syntax as to be
> absurd. Just as I think the only way to justify claiming that Python has
> pointers is to do so much violence to the concept of pointer and to
> Python's object model as to also be absurd.
>
> That's not to say that the general concept of references (as in "to refer
> to") isn't valuable when discussing Python. If you want to say that
> (e.g.) following
>
> x = 1
>
> the name "x" refers to (or even points to!) the object 1, my objections
> will be mild or non-existent. In that sense, it's probably impossible to
> program without some sort of "references": the computer manipulates
> variables or objects directly, while we manipulate characters in source
> code. The only way to write a program is to use some abstract thing (a
> name, an offset, whatever) that refers, in some fashion, to a collection
> of bits in the computer's memory. But to go from that to the idea that
> (say) x is a pointer does so much violence to the concept of pointer and
> has so much room for confusion that it is actively harmful.
>

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