Asp Forum - Re: Modifying Class Object

aahz

2/13/2010 3:31:00 PM

In article <mailman.2323.1265836683.28905.python-list@python.org>,
Steve Holden <steve@holdenweb.com> wrote:
>
>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.

IIRC, I've seen ctypes code that uses id() to get access to the object,
but (obviously) I don't think that invalidates your point[er].
--
Aahz (aahz@pythoncraft.com) <*> http://www.python...

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"

20 Answers

Alf P. Steinbach

2/13/2010 4:08:00 PM

* Aahz:
> In article <mailman.2323.1265836683.28905.python-list@python.org>,
> Steve Holden <steve@holdenweb.com> wrote:
>> 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.
>
> IIRC, I've seen ctypes code that uses id() to get access to the object,

Dino Viehland gave this code:

<quote author="Dino Viehland">
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
</quote>

> but (obviously) I don't think that invalidates your point[er].

For my part I didn't think the above would be possible without enumerating all
objects. I'm guessing that Steve didn't think so either. However, I seriously
doubt that an agreement with my earlier statements of that was his point,
considering the "if" above, which seems to imply to the reader that instead I'd
argued what he's challenging.

Perhaps Steve was just confused.

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

It took a long time to get the wild horses reined in in that direction.

But then two others ended up arguing that Python does not have references, with
one of them maintaining that "refers to" in the language spec does not mean
"refers to", but instead means "refers to", so I'm guessing it's religious, yes?

Cheers,

- Alf

aahz

2/14/2010 2:42:00 AM

In article <hl6ilk$f7h$1@news.eternal-september.org>,
Alf P. Steinbach <alfps@start.no> wrote:
>
>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.
--
Aahz (aahz@pythoncraft.com) <*> http://www.python...

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"

Steve Howell

2/14/2010 2:55:00 AM

On Feb 13, 6:41 pm, a...@pythoncraft.com (Aahz) wrote:
> In article <hl6ilk$f7...@news.eternal-september.org>,
> Alf P. Steinbach <al...@start.no> wrote:
>
>
>
> >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.

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

Alf P. Steinbach

2/14/2010 3:44:00 AM

* Aahz:
> In article <hl6ilk$f7h$1@news.eternal-september.org>,
> Alf P. Steinbach <alfps@start.no> wrote:
>> 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.

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_s...

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

2/14/2010 3:54:00 AM

On Sat, 13 Feb 2010 18:54:34 -0800, Steve Howell wrote:

> On Feb 13, 6:41Â pm, a...@pythoncraft.com (Aahz) wrote:

> > 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."

"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]
i += 1
data[i] = 'zzz'

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

--
Steven

Steve Howell

2/14/2010 4:11:00 AM

On Feb 13, 7:53 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 13 Feb 2010 18:54:34 -0800, Steve Howell wrote:
> > On Feb 13, 6:41 pm, a...@pythoncraft.com (Aahz) wrote:
> > > 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."
>
> "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]
> i += 1
> data[i] = '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

2/14/2010 5:14:00 AM

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.

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.

--
Steven

Steve Howell

2/14/2010 5:34:00 AM

On Feb 13, 9:13 pm, Steven D'Aprano <st...@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.

Steven D'Aprano

2/14/2010 7:22:00 AM

On Sat, 13 Feb 2010 21:33:50 -0800, Steve Howell wrote:

> 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/...(C++)

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

--
Steven

Alf P. Steinbach

2/14/2010 7:41:00 AM

* Steven D'Aprano:
> On Sat, 13 Feb 2010 21:33:50 -0800, Steve Howell wrote:
>
>> 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/...(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%27s_....

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

comp.lang.python

Re: Modifying Class Object

aahz

Alf P. Steinbach

aahz

Steve Howell

Alf P. Steinbach

Steven D'Aprano

Steve Howell

Steven D'Aprano

Steve Howell

Steven D'Aprano

Alf P. Steinbach

x Login to ForumsZone