anything like C++ references?

[Stephen Horne]

On Mon, 14 Jul 2003 06:28:09 GMT, "Bryan" <belred1 at yahoo.com> wrote:

>
>"Stephen Horne" <intentionally at blank.co.uk> wrote in message
>news:rp94hvc8fg6h91oe7ctqq9jn9ku3nlud1k at 4ax.com...
>> On Sun, 13 Jul 2003 22:42:21 GMT, "Bryan" <belred1 at yahoo.com> wrote:
>>
>> >
>> >> 3.  Why is there no way to reference an immutable object via a
>> >> pointer, other than stuffing it into a mutable object designed for
>> >> some purpose other than simple pointer behaviour?
>> >>
>> >
>> >>>> a = (1, 2, 3)
>> >>>> b = a
>> >>>> id(a)
>> >15471760
>> >>>> id(b)
>> >15471760
>> >>>> print b[1]
>> >2
>> >>>>
>> >
>> >
>> >i just referenced an immutable object via a "pointer" and i __did_not__
>> >stuff it into a mutable object as you say.
>> >a and b "point" to the same object.
>>
>> Technically, but what is the point? You can't do pointer-style things
>> with it. You can't change the object in any way without changing the
>> id, and you can't use the mechanism to, for instance, allow 'var'
>> parameters.
>>
>
>can you show what functionality is missing by not being able to do
>"pointer-style things"?  here are two variables:
>
>a = (1, 2, 3)
>b = [1, 2, 3]
>
>one immutable, one mutable.  please show an example of what "pointer-style
>things" you would like to do.

In my view, mutability should be a property of *objects* - not the
same as values, in the pedantic language that has become necessary in
this thread. The existence of mutability shouldn't break the principle
of variables being bound to values.

This is my point. Pointer types are a side issue - something that
becomes necessary (or rather more obviously important) if the
principle of variables being bound to values is respected. This
doesn't mean that Python can't use binding of variables to objects as
an implementation, but that implementation shouldn't be visible
(except for performance, and for operations that explicitly deal with
objects rather than values) in the results.

Starting from your example, I'd want to see results like this...

>>> a = [1, 2, 3]
>>> b = a
>>> c = (1, 2, 3)
>>> d = c
>>> b[2] = 4
>>> a
[1, 2, 3]
>>> b
[1, 2, 4]
>>> d[2] = 4
Traceback (most recent call last):
  File "<stdin>", line 8, in ?
TypeError: object doesn't support item assignment


Having done this, mutable objects could not be abused to give
pointer-style functionality (a fact of life at the moment) so the need
for real explicit pointers should become obvious.

>i've read this entire thread so far, and from a practical point of view
>(because that's all i really care about and what pays the bills), i really
>don't understand what the problem is.  personally, i don't care about the
>strict definitions of computer science terms and what "variable" or
>"pointer" means.  i do care about how fast problems can be solved, how much
>resources must be involved in solving that problem, and how much money can
>be made/saved.  for me, python is a winner in all this area.  not having
>pointers like c/c++ is such a blessing.  i can't believe anyone would even
>suggest that pointers and/or doing things with pointers be brought into
>python.  ok... one more time... let's bring this conversation down to
>something practical.   please show an example of pointer-style functionality
>in any language that is missing/awkward/complicated in python.  i'm not an
>expert in python, i'm just very curious to understand what the true
>practical issue is.

There is none that is currently missing because mutable objects can be
abused to create the required effect. If Python respected the concept
of variables being bound to values, though, that wouldn't be true.

You wouldn't be able to write...

>>> def f(x) :
...   x[0] += 1
...
>>> a = [1]
>>> f(a)

Or rather you could, but you'd get...

>>> a
[1]

...and not...

>>> a
[2]

So instead of abusing lists, you'd have to use an explicit pointer
type...

>>> def f(x) :
...   *x += 1
...
>>> a = 1
>>> f(&a)
>>> a
2

Note - in many cases, you could return multiple values and avoid the
need for pointers. That wouldn't be the case, however, for objects
which don't support copying.

It *might* be possible to pass such an object directly into a function
(depending on how the variable-to-value binding is implemented) but
modifying the parameter would require that it binds to a new object -
a copy of the original object - to prevent the mutation of the callers
variables. Passing the parameter and returning it *might* be
acceptable, but modifying it within the function would require copying
of the object.

As there are a number of important object types that don't (and
shouldn't) support copying, this wouldn't be a trivial concern.