python bug in this list implementation?

[Chris Smith]

Hi,

I've been working on some multi-dimensional lists and I've encountered some
very strange behaviour in what appears to be simple code, I'm using python
2.4.2 and IDLE. If anyone can tell me why it's behaving so strange please
let me know, any improvements to my general coding style are also
appreciated.
code below:

import sys
import copy

grid = []
oGrid = []
sGrid = []

def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.

for line in f:
aLine = line.strip().split(',')
if aLine != [""]:
for i in xrange(len(aLine)):
aLine[i] = int(aLine[i])
grid.append(aLine)

oGrid = copy.deepcopy(grid)
sGrid.append(copy.deepcopy(grid))
def printGrid():
print "original grid:"
for line in oGrid:
print line #why doesn't this print anything?

print "S grid:"
for line in sGrid:
print line #this prints the grid but the formatting is all over the
place.

print "Iteration grid: "
for line in grid:
print line #works fine!

if __name__ == "__main__":
createGrid()
printGrid()

##PRODUCES THE FOLLOWING OUTPUT:
##
##original grid:
##S grid:
##[[0, 0, 0, 1, 5, 0, 0, 7, 0], [1, 0, 6, 0, 0, 0, 8, 2, 0], [3, 0, 0, 8, 6,
0, 0, 4, 0], [9, 0, 0, 4, 0, 0, 5, 6, 7], [0, 0, 4, 7, 0, 8, 3, 0, 0], [7,
3, 2, 0, 1, 6, 0, 0, 4], [0, 4, 0, 0, 8, 1, 0, 0, 9], [0, 1, 7, 0, 0, 0, 2,
0, 8], [0, 5, 0, 0, 3, 7, 0, 0, 0]]
##Iteration grid:
##[0, 0, 0, 1, 5, 0, 0, 7, 0]
##[1, 0, 6, 0, 0, 0, 8, 2, 0]
##[3, 0, 0, 8, 6, 0, 0, 4, 0]
##[9, 0, 0, 4, 0, 0, 5, 6, 7]
##[0, 0, 4, 7, 0, 8, 3, 0, 0]
##[7, 3, 2, 0, 1, 6, 0, 0, 4]
##[0, 4, 0, 0, 8, 1, 0, 0, 9]
##[0, 1, 7, 0, 0, 0, 2, 0, 8]
##[0, 5, 0, 0, 3, 7, 0, 0, 0]

[Fredrik Lundh]

Chris Smith wrote:

I've been working on some multi-dimensional lists and I've encountered some
very strange behaviour in what appears to be simple code, I'm using python
2.4.2 and IDLE. If anyone can tell me why it's behaving so strange please
let me know, any improvements to my general coding style are also
appreciated.
code below:

import sys
import copy

grid = []
oGrid = []
sGrid = []

def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.

for line in f:
aLine = line.strip().split(',')
if aLine != [""]:
for i in xrange(len(aLine)):
aLine[i] = int(aLine[i])
grid.append(aLine)
at this point, grid contains a list of lists.
oGrid = copy.deepcopy(grid)
if you assign to a name inside a function, that name is considered to be
*local*, unless you specify otherwise. in other words, this doesn't touch
the *global* (module-level) oGrid variable.
sGrid.append(copy.deepcopy(grid))
here you add a list of lists to a list. the result is a list with a single item.
def printGrid():
print "original grid:"
for line in oGrid:
print line #why doesn't this print anything?
because the *global* oGrid is still empty.
print "S grid:"
for line in sGrid:
print line #this prints the grid but the formatting is all over the
place.
because sGrid contains a single item; a copy of your original grid.
print "Iteration grid: "
for line in grid:
print line #works fine!

as expected.

I suggest reading up on list methods and global variables in your favourite
python tutorial.

also read:

http://www.catb.org/~esr/faqs/smart-...html#id3001405

</F>

[Steven D'Aprano]

On Wed, 28 Dec 2005 07:29:41 +0000, Chris Smith wrote:

Hi,

I've been working on some multi-dimensional lists and I've encountered some
very strange behaviour in what appears to be simple code, I'm using python
2.4.2 and IDLE. If anyone can tell me why it's behaving so strange please
let me know, any improvements to my general coding style are also
appreciated.
How about some advice about how to ask smart questions?

*What* is "so strange" about the behaviour -- what are you expecting? You
shouldn't expect people to read your mind and guess what behaviour you
expect, you should say "I expect X Y and Z, but I get A B and C instead."
In the future, you may not have somebody like Fredrik willing to read your
code trying to guess what you think it should do.

code below:

import sys
import copy

grid = []
oGrid = []
sGrid = []
Using global variables is not usually recommended. It is usually better to
pass local variables from function to function. That will avoid the bugs
which your code has, which Fredrik has already pointed out.

def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.
Why do you need a raw string? It isn't wrong to do one, but it is rather
unusual and unnecessary.
[snip] oGrid = copy.deepcopy(grid)
sGrid.append(copy.deepcopy(grid))

Why are you doing deepcopies of the lists? That seems to be unnecessary.

Oh, another bit of advice: any time you think you've found a bug in
Python, it almost always is a bug in your code.

--
Steven.

[Christoph Zwerschke]

Steven D'Aprano wrote:

On Wed, 28 Dec 2005 07:29:41 +0000, Chris Smith wrote:

def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.

Why do you need a raw string? It isn't wrong to do one, but it is rather
unusual and unnecessary.

Chris is probably working on Windows where it is handy to enter paths as
raw strings because of the backslashes. Unusual however, and problematic
if you want to use the program on other platforms, is opening a text
file in binary mode.

-- Christoph

[Steven D'Aprano]

On Wed, 28 Dec 2005 15:07:52 +0100, Christoph Zwerschke wrote:

Steven D'Aprano wrote:

On Wed, 28 Dec 2005 07:29:41 +0000, Chris Smith wrote:

>>
def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.

Why do you need a raw string? It isn't wrong to do one, but it is rather
unusual and unnecessary.

Chris is probably working on Windows where it is handy to enter paths as
raw strings because of the backslashes. Unusual however, and problematic
if you want to use the program on other platforms, is opening a text
file in binary mode.

Sure, but then the file name doesn't have any backslashes.

I've never understood why binary mode is supposed to be bad. By my
understanding, binary mode simply means that no line endings are
translated, regardless of whether the file uses \n, \r or a combination of
the two. Surely the worst that can happen in binary mode is that your
strings end up having some carriage returns you have to deal with yourself?

--
Steven.

[Roel Schroeven]

Steven D'Aprano wrote:

On Wed, 28 Dec 2005 15:07:52 +0100, Christoph Zwerschke wrote:

Chris is probably working on Windows where it is handy to enter paths as
raw strings because of the backslashes. Unusual however, and problematic
if you want to use the program on other platforms, is opening a text
file in binary mode.

I've never understood why binary mode is supposed to be bad. By my
understanding, binary mode simply means that no line endings are
translated, regardless of whether the file uses \n, \r or a combination of
the two. Surely the worst that can happen in binary mode is that your
strings end up having some carriage returns you have to deal with yourself?

Yes. The larger problem is when you don't explicitly use binary mode
while handling binary data on other platforms, and then port it to Windows.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven