Wildemar Wildenburger wrote: > Jorge Godoy wrote: > > Wildemar Wildenburger <[EMAIL PROTECTED]> writes: > > > >> I don't know how else to call what I'm currently implementing: An > object that > >> behaves like a list but doesn't store it's own items but rather > pulls them > >> from a larger list (if they match a certain criterion). > >> Changes to the filter are instantly reflected in the underlying list. > >> Clear enough? > > > > It looks like you're implementing a callable to me. This is a method > that > > returns results based on some input -- here your original list and > filter. > > Then you'll use this method wherever you need that filtered list. > > > Ok, so I'm not clear enough ;) . > I don't just want to extract certain elements from a list, I want an > object that looks like a list, however all changes made to that object > are automagically reflected in the original list. (I guess that is one > of those 'if it's hard to explain, ...' cases.) > > I should have included an example right away ... here goes: > > # I have a list > l = [1, 2, 3, 4, 5, 6, 7] > > # I then want to create a Filter instance > # (Filter beeing a *class* implemented by me) > # where isEven() returns True whenever an item of l > # should be included in f (in this case, even numbers). > # (I'm asking if something like this exists in the libs > # or elsewhere) > f = Filter(l, isEven) > > # The desired behavior now goes something like this: > f > >>> [2, 4, 6] > del f[1] > f > >>> [2, 6] > l > >>> [1, 2, 3, 5, 6, 7] > f.append(77) > f > >>> [2, 6, 77] > # 77 being intentionally uneven > l > >>> [1, 2, 3, 5, 6, 7, 77] > # could be [1, 2, 3, 5, 6, 77, 7] as well > # I don't care here > > # and so forth ... > > 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.
This is a classic cause of user perplexity - they update a record without being aware that they are using a view and suddenly it "disappears". 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. It might be better if you were to explain your use case: what is this beast supposed to be for? > > I don't believe it is generic. Nobody knows your data specs or filtering > > needs. > Hence the additional function in the Filter constructor ;) . You suggest > the same thing below, so that is obviously no problem. > > > Use of list comprehension might make it easier to code this: > > > > <snip elaborate example> > I sort of wanted to avoid these. Though my lists shouldn't terribly > long, so performance is not an issue so much. I simply want to avoid > having two datasets that I have to sync. Major pain, I believe. > > > Coding all that really is quite straight forward, but it is a lot of > mule-work. I hoped (no, I still hope) that there might be somethin like > that around already. > > 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 ;-) 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? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
