anything like C++ references?

[Stephen Horne]

On 13 Jul 2003 20:18:25 -0500, Ian Bicking <ianb at colorstudy.com>
wrote:

>I think, then, that Stephen maybe wants to do something like:
>
>>>> a = ref(1)
>>>> b = a
>>>> b is a
>True
>>>> a + 2
>3
>>>> a = 5
>>>> b
>5
>
>And so on.  This is all quite doable in Python (implementation of ref
>left to the reader), except for the "a = 5" part.  Instead you'd have to
>do something like "a.set(5)".  Even though it is doable, of course, it's
>by way of clever hacks.

Well, during the 'debate', that's the basic idea that involved -
except that I'd use explicit pointer-dereferencing syntax.

Imagine, for instance, changing all assignments and other 'copying' to
use a copy-on-write system. Then add a pointer type and a 'newcopyof'
operator. And nick the C-style prefix '*' for dereferencing and add
'&' as a 'make a pointer to this object' operator (absolutely NOT a
physical memory address).

>>> a = 5
>>> b = a
>>> b is a
False

>>> a = &5
>>> b = a
>>> *b is *a
True

>>> a = &5
>>> b = newcopyof a        #  could be "b = &(*a)" in principle
>>> *b is *a
False

>>> a = BadPtr
>>> b = *a
Traceback (most recent call last):
  File "<stdin>", line 11, in ?
BadDeref: pointer does not reference a valid object

>>> a = *1
Traceback (most recent call last):
  File "<stdin>", line 12, in ?
TypeError: object doesn't support dereference operator


No need for a 'delete' equivalent because of garbage collection. No
possibility of referencing a bad pointer as there is no way to create
a bad pointer - except, of course, for the explicit BadPtr (or
whatever) which throws an exception if dereferenced.

>The problem that Stephen is not appreciating is that this sort of
>reference implies that "a" is a typed variable -- of type "pointer",
>somehow implicitly declared when it was initially assigned a ref
>object.  (He's not alone, because just a little while ago someone
>proposed a way to overload the meaning of "=", to achieve largely the
>same functionality)  

No - I'm aware of the issue. When people use lists to fake pointers,
they already need explicit notation to tell Python what they are
doing. I'd just rather go back to having explicit pointers, though
implemented in a way which is appropriate to scripting languages and
which eliminates the major reliability issues of C-like pointer
mechanisms.

Using this approach, I don't need to declare variable types but I do
need to be explicit about when I'm using pointed-to-values and when
I'm using the pointers themselves.

Self-dereferencing pointers might also be nice in some ways, but with
serious problems. In C++, binding to the referenced object is done in
the declaration. That can't happen in Python, so a different method
would be needed - a special assignment operator, probably.

That then leads to the fundamental flaw. This couldn't be used to do
what, in C++, it does best - mimicking what Pascal calls 'var'
parameters.

If there were a 'procedure' abstraction, distinct from 'function', I
might be happy for all parameters to be implicitly dereferenced
pointers - I'd be happy being unable to change the pointer in this
case (in fact I'd like it enforced) - to get var parameter like
behaviour. There are nasty subtleties, though (what if someone creates
a pointer to the parameter, for instance - can it be used to change
the supposedly fixed pointer?). The C-like approach of just passing a
pointer as the expected parameter type has the advantage of simplicity
if nothing else.

>Anyway, that's my attempt at empathy with Stephen, if not agreement.  If
>he is wanting something other than what I've described, he should give
>other examples, because code examples are better than words.

I hope I've explained, now. It wasn't in my mind when I started out,
but it would certainly be a way to solve what I see as serious
problems.

A realistic change for Python? - I doubt it. It could be technically
feasable, perhaps (a 'from future' thing adding copy-on-write and the
new operators etc) but interaction with past modules would create
problems. And with my very limited understanding of Python internals,
I'm sure I'm missing much bigger problems. Not to mention that at this
point, the change would probably be so fundamental as to actually
create a new language.

This does, however, give an alternative that *could* have been
plausible (in a parallel universe, perhaps), and which would not have
resulted in certain common problems that do occur now.