In article <[EMAIL PROTECTED]>, pataphor <[EMAIL PROTECTED]> wrote:
> On Tue, 20 May 2008 06:12:01 -0500 > David C. Ullrich <[EMAIL PROTECTED]> wrote: > > > Well, ok. Like I said, I never _took_ the position that it _should_ > > be a list of lists, I just said I didn't see the advantage to using > > a single list. > > I'm now thinking about a list of lists containing single element lists. > > def test(): > n = 3 > R = range(n) > M = [[[i+j*n] for i in R] for j in R] > for L in M: > print L > row2 = M[1] > print > print row2 > col3 = [L[2] for L in M] > print col3 > col3[1][0]=9 > > print col3 > print row2 > print > for L in M: > print L > > if __name__=='__main__': > test() > > The idea is to use a single element list as kind of storage facility. > That enables me to copy a column, then change something in that column > and make the change turn up in the matrix and even in a previously made > copy of a row that shared the specific element. > > > Today's little joke: Long ago I would have solved > > this by storing the data as a list of rows and _also_ > > a list of columns, updating each one any time the > > other changed. Just goes to show you things > > could always be worse... > > Well have I ever ... I only thought about this last week and I > actually thought it was a *good* idea. Sorry. If you really want to do this you could keep things in sync automatically by writing the appropriate __setitem__ and resolving never to modify the data except through that... def whatever.__setitem__(self, (row,col), value): self.rows[row][col] = value self.cols[col][row] = value Seems to me like an, um, "untenable" waste of space. And you'd need to be certain to never set anything except through self[row,col]; as far as I can see anything like setrow() would be a loop "for col in range(width): self[row,col] =". Hmm. You could keep the data in some object that encapsulates the two double lists and use some fancy feature (__getattribute__?) to make certain that the only possible access to the data was through __getitem__... > I only gave up on it because > now I would have to keep track of how far the two views are out of > sync, because some operation could use data that was modified by an > other view. Zipstar transposition is very handy for syncing, but it is > also very expensive. But probably not for you. > > > Expressing interest is a big mistake... > > How so? ;-) > > > Sometime soon a thread will appear titled something > > like "indexed attributes" with a stripped-down but > > functional example of what I have in mind for Matrix > > I can't wait! Keep up the good work. > > P. -- David C. Ullrich -- http://mail.python.org/mailman/listinfo/python-list
