"filtered view" upon lists?

[Steve Holden]

Wildemar Wildenburger wrote:
> Jorge Godoy wrote:
>  > Wildemar Wildenburger <wildemar at freakmail.de> 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