Steve Holden wrote: >> I think SQL views are the direct analog. >> > I don't think they are. If you add a non-conforming row to a SQL view it doesn't appear int he view. If you modify a row in an updateable view so it no longer confirms with the view's conditions it disappears from the view.
Me and my wording again: I typed 'direct analog' but meant 'somewhat analog'. > Also you don't say whether changes to l are supposed to be reflected in f in the same way that changes to f are reflected in l. Right. Yes, the synchronicity (a word?) is meant to be in both directions. > It might be better if you were to explain your use case: what is this beast supposed to be for? I have a database of interconnected objects. Each object has a list tuples; these tuples hold references to other objects and details about the type of connection. The 'views' I am imagining are sub-lists of this one list, based on the connection types. Order is important here, that's why I'm not using sets. BTW: I have gone the way of nested lists before and found it too rigid and complicated to use. >> A bit clearer now? >> >Hardly at all. Frankly it doesn't seem as though you really know what > the specifications are yourself, so you can hardly expect us to divine > them by use of our psychic powers. Besides which, psychic powers cost > extra ;-) Right again. I'm not sure what I want yet as I'm still exploring ideas. If something /like/ the above had existed (which by now I'm gathering is not the case) I'd just adapted my ideas to the specs given. > So give us that use case so we get a bit more insight into why you even see the need for such a thing and how you want it ti behave. Or is all this just theoretical? No no, its very much real. Just not as fleshed out as it might be --- I'm sort of an explorative coder; I usually don't know how something is going to work until it works. Thx for the effort :) wildemar -- http://mail.python.org/mailman/listinfo/python-list
