Automatic debugging of copy by reference errors?

[Niels L Ellegaard]

Is there a module that allows me to find errors that occur due to copy
by reference? I am looking for something like the following:

>>import mydebug
mydebug.check copybyreference = True
a=2
b=[a]
a=4

Traceback (most recent call last):
File "<stdin>", line 1, in ?
CopyByReference Error: Variable b refers to variable a, so please do not
change variable a.

Does such a module exist?
Would it be possible to code such a module?
Would it be possible to add the functionality to array-copying in
numpy?
What would be the extra cost in terms of memory and CPU power?

I realize that this module would disable some useful features of the
language. On the other hand it could be helpful for new python users.

Niels

[Russ]

Niels L Ellegaard wrote:

Is there a module that allows me to find errors that occur due to copy
by reference? I am looking for something like the following:

I don't have a solution for you, but I certainly appreciate your
concern. The copy by reference semantics of Python give it great
efficiency but are also its achille's heel for tough-to-find bugs.

I once wrote a simple "vector" class in Python for doing basic vector
operations such as adding and subtracting vectors and multiplying them
by a scalar. (I realize that good solutions exist for that problem, but
I was more or less just experimenting.) The constructor took a list as
an argument to initialize the vector. I later discovered that a
particularly nasty bug was due to the fact that my constructor "copied"
the initializing list by reference. When I made the constructor
actually make its own copy using "deepcopy," the bug was fixed. But
deecopy is less efficient than copy by reference, of course.

So a fundamental question in Python, it seems to me, is when to take
the performance hit and use "copy" or "deepcopy."

If a debugger could tell you how many references exist to an object,
that would be helpful. For all I know, maybe some of them already do. I
confess I don't use debuggers as much as I should.

[Carl Banks]

Russ wrote:

If a debugger could tell you how many references exist to an object,
that would be helpful.

import sys
sys.getrefcount (a)

But I doubt it would be very helpful.

Carl Banks

[Carl Banks]

Niels L Ellegaard wrote:

Marc 'BlackJack' Rintsch wrote:

In <11************ **********@n67g 2000cwd.googleg roups.com>, Niels L
Ellegaard wrote:

I have been using scipy for some time now, but in the beginning I made
a few mistakes with copying by reference.

But "copying by reference" is the way Python works. Python never copies
objects unless you explicitly ask for it. So what you want is a warning
for *every* assignment.

Maybe I am on the wrong track here, but just to clarify myself:

I wanted a each object to know whether or not it was being referred to
by a living object, and I wanted to warn the user whenever he tried to
change an object that was being refered to by a living object.

This really wouldn't work, trust us. Objects do not know who
references them, and are not notified when bound to a symbol or added
to a container. However, I do think you're right about one thing: it
would be nice to have a tool that can catch errors of this sort, even
if it's imperfect (as it must be).

ISTM the big catch for Fortran programmers is when a mutable container
is referenced from multiple places; thus a change via one reference
will confusingly show up via the other one. (This, of course, is
something that happens all the time in Python, but it's not something
people writing glue for numerical code need to do a lot.) Instead of
the interpreter doing it automatically, it might be better (read:
possible) to use an explicit check. Here is a simple, untested
example:
class DuplicateRefere nce(Exception):
pass

def _visit_containe r(var,cset):
if id(var) in cset:
raise DuplicateRefere nce("container referenced twice")
cset.add(id(var ))

def assert_no_dupli cate_container_ refs(datalist,c set=None):
if cset is None:
cset = set()
for var in data:
if isinstance(var, (list,set)):
_visit_containe r(var,cset)
assert_no_dupli cate_container_ refs(var,cset)
elif isinstance(var, dict):
_visit_containe r(var,cset)
assert_no_dupli cate_container_ refs(var.iterva lues(),cset)
Then, at important points along the way, call this function with data
you provide yourself. For example, we might modify your example as
follows:

import os
output=[]
firstlines =[0,0]
for filename in os.listdir('.') :
try:
firstlines[0] = open(filename," r").readline s()[0]
firstlines[1] = open(filename," r").readline s()[1]
output.append(( filename,firstl ines))
except (IOError, IndexError):
# please don't use bare except unless reraising exception
continue
assert_no_dupli cate_container_ refs([output,firstlin es])
print output
We passed the function output and firstlines because those are the two
names you defined yourself. It'll check to see if any containers are
referenced more than once. And it turns out there are--firstlines is
referenced many times. It'll raise DuplicateRefere nce on you.

There's plenty of room for improvement in the recipe, for sure. It'll
catch real basic stuff, but it doesn't account for all containers, and
doesn't show you the loci of the duplicate references.

Now, to be honest, the biggest benefit of this check is it gives
newbies a chance to learn about references some way other than the hard
way. It's not meant to catch a common mistake, so much as a
potentially very confusing one. (It's really not a common mistake for
programmers who are aware of references.) Once the lesson is learned,
this check should be put aside, as it unnecessarily restricts
legitimate use of referencing.
Carl Banks

[greg]

Russ wrote:

The copy by reference semantics of Python give it great
efficiency but are also its achille's heel for tough-to-find bugs.

You need to stop using the term "copy by reference",
because it's meaningless. Just remember that assignment
in Python is always reference assignment. If you want
something copied, you need to be explicit about it.

I later discovered that a
particularly nasty bug was due to the fact that my constructor "copied"
the initializing list by reference.

The reason you made that mistake was that you were
using the wrong mental model for how assignment works
in Python -- probably one that you brought over from
some other language.

When you become more familiar with Python, you won't
make mistakes like that anywhere near as often. And
if you do, you'll be better at recognising the
symptoms, so the cause won't be hard to track down.

So a fundamental question in Python, it seems to me, is when to take
the performance hit and use "copy" or "deepcopy."

Again, this is something you'll find easier when
you've had more experience with Python. Generally,
you only need to copy something when you want an
independent object that you can manipulate without
affecting anything else, although that probably
doesn't sound very helpful.

In your vector example, it depends on whether you
want your vectors to be mutable or immutable. It
sounds like you were treating them as mutable, i.e.
able to be modified in-place. In that case, each
vector obviously needs to be a new object with the
initial values copied into it.

The alternative would be to treat your vectors as
immutable, i.e. once created you never change their
contents, and any operation, such as adding two
vectors, produces a new vector holding the result.
In that case, two vectors could happily share a
reference to a list of values (as long as there is
nothing else that might modify the contents of the
list).

--
Greg

[Beliavsky]

Carl Banks wrote:

Niels L Ellegaard wrote:

Marc 'BlackJack' Rintsch wrote:

In <11************ **********@n67g 2000cwd.googleg roups.com>, Niels L
Ellegaard wrote:
I have been using scipy for some time now, but in the beginning I made
a few mistakes with copying by reference.
But "copying by reference" is the way Python works. Python never copies
objects unless you explicitly ask for it. So what you want is a warning
for *every* assignment.

Maybe I am on the wrong track here, but just to clarify myself:

I wanted a each object to know whether or not it was being referred to
by a living object, and I wanted to warn the user whenever he tried to
change an object that was being refered to by a living object.

This really wouldn't work, trust us. Objects do not know who
references them, and are not notified when bound to a symbol or added
to a container. However, I do think you're right about one thing: it
would be nice to have a tool that can catch errors of this sort, even
if it's imperfect (as it must be).

ISTM the big catch for Fortran programmers is when a mutable container
is referenced from multiple places; thus a change via one reference
will confusingly show up via the other one.

As a Fortranner, I agree. Is there an explanation online of why Python
treats lists the way it does? I did not see this question in the Python
FAQs at http://www.python.org/doc/faq/ .

Here is a short Python code and a Fortran 95 equivalent.

a = [1]
c = a[:]
b = a
b[0] = 10
print a,b,c

output: [10] [10] [1]

program xalias
implicit none
integer, target :: a(1)
integer :: c(1)
integer, pointer :: b(:)
a = [1]
c = a
b = a
b(1) = 10
print*,a,b,c
end program xalias

output: 10 10 1

It is possible to get similar behavior when assigning an array (list)
in Fortran as in Python, but one must explicitly use a pointer and "=>"
instead of "=". This works well IMO, causing fewer surprises, and I
have never heard Fortranners complain about it.

Another way of writing the Fortran code so that "a" and "b" occupy the
same memory is to use EQUIVALENCE.

program xequivalence
implicit none
integer :: a(1),b(1)
integer :: c(1)
equivalence (a,b)
a = [1]
c = a
b = a
b(1) = 10
print*,a,b,c
end program xequivalence

output: 10 10 1

EQUIVALENCE is considered a "harmful" feature of early FORTRAN
http://www.ibiblio.org/pub/languages/fortran/ch1-5.html .

[Marc 'BlackJack' Rintsch]

In <11************ *********@79g20 00cws.googlegro ups.com>, Beliavsky wrote:

>ISTM the big catch for Fortran programmers is when a mutable container
is referenced from multiple places; thus a change via one reference
will confusingly show up via the other one.

As a Fortranner, I agree. Is there an explanation online of why Python
treats lists the way it does? I did not see this question in the Python
FAQs at http://www.python.org/doc/faq/ .

This question sounds as if lists are treated somehow special. They are
treated like any other object in Python. Any assignment binds an object
to a name or puts a reference into a "container" object.

Ciao,
Marc 'BlackJack' Rintsch

[Russ]

greg wrote:

You need to stop using the term "copy by reference",
because it's meaningless. Just remember that assignment

I agree that "copy by reference" is a bad choice of words. I meant pass
by reference and assign by reference. But the effect is to make a
virtual copy, so although the phrase is perhaps misleading, it is not
"meaningles s."

<cut>

Again, this is something you'll find easier when
you've had more experience with Python. Generally,
you only need to copy something when you want an
independent object that you can manipulate without
affecting anything else, although that probably
doesn't sound very helpful.

Yes, I realize that, but deciding *when* you need a copy is the hard
part.