On Sun, 18 May 2008 08:50:23 +0200, pataphor <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] says... > >> >> window.pos = (x,y) >> >> >> >> seems more natural than >> >> >> >> window.SetPos(x,y); > >Yes, and to assign a row in a matrix I'd also like to use either tuples >or lists on the right side. Heh - in the current (flawed) implementation you can say m.row[0] = 'Hello'; m.row[1]= 'World!' .Not that I see why you'd want to, but that happened in the test code just to check that things were as general as I wanted - sure enough m.row[0] + m.row[1] comes out to ['HW', 'eo', 'lr', ''ld', 'o!']. >> def __add__(self, other): >> return Row([x + y for x, y in zip(self, other)]) >> >> worked as hoped if self is a Row and other is a >> Row _or_ a list.) >> >> Anyway, my m.rows[j] can't be a list, because >> I want to be able to say things like >> m.rows[0] += c*m.rows[2]. Allowing >> m.rows[j] = [1,2,3] seems convenient, while >> requiring m.rows[j] = Row([1,2,3]) fixes >> this problem. Hmm. > >I'm not sure how far you'd go along with Gabriel's idea of decoupling >views from data but I think there isn't even a need for using a matrix >as the underlying data type. Why not use a flat list and compute matrix >positions according to a row or column adressing scheme on the fly? Is there some reason that would be better? It would make a lot of the code more complicated. Ok, it would require only one bit of added code, I suppose, but I don't see the plus side. Hmm. It might actually _reduce_ the total amount of code, since the code to access columns has to exist anyway and rows could use the same code as columns with different "start" and "skip". And come to think of it rows and columns could be obtained just with a slice of the data. So column access might even be more efficient. But I expect that row access will happen a lot more often than column access. >P. David C. Ullrich -- http://mail.python.org/mailman/listinfo/python-list
