[Urwid] How do you use SimpleListWalker?

Dominic LoBue dom.lobue at gmail.com
Sat Jun 20 02:32:35 EDT 2009

I see, thanks for the heads up.

I did some tests while writing my message threading module and as far
as I can tell trying to do threading piecemeal is many times slower. I
suppose instead of threading all the messages from scratch every
single time the program is loaded I can cache the results of the
threader with pickle and just load that instead, but that still
doesn't help the fact that if you have a lot of email, the result is
going to be a lot of threads.

Right now the threader stores results in an internal list that it can
modify on the fly so new messages found can be inserted into the
thread with as little fuss as possible. The results are a simple list
with each thread being a custom dict class I made called that looks
like this: {'references':[], 'subjects':[], 'labels': [],
'messages':[]}. Inside of references, subjects, and labels is just a
list of strings. Inside messages are the results my Whoosh index,
which is a dict of all the headers from an email.

So I don't have to apply widgets to each message in the threaded list,
or make a copy of my threaded list which I'd then have to somehow keep
in sync with the master list, I thought I'd just add the button widget
methods directly to my conversation dict class. That way instead of
doing [urwid.Text(x) for x in threadedlist] I just do
threadmodule.convClass = convClasswithButtonMethods.

I suppose I can also modify the internal list structure that my
threading class holds to instead be a SimpleListWalker so I don't have
to load the results into that when I'm done.

Other than having to now muck around with metaclasses, do you forsee
any performance problems with how I'm trying to do this? Or is there a
better way that I just don't know about?


On Fri, Jun 19, 2009 at 11:39 AM, Ian Ward<ian at excess.org> wrote:
> Dominic LoBue wrote:
>> What makes SimpleListWalker inappropriate for larger lists? For a quick test
>> I used Text rather than Button, but I'm able to scroll through all 2600
>> conversation threads rather quickly. No CPU spikes or anything.
> There are all the usual reasons for not wanting big lists, which are
> implemented as arrays in python:
> - Inserting items is O(n)
> - Deleting items is O(n)
> - Must fit in memory*
> Also for Urwid you will need to create all your widgets for every item
> in advance, which can introduce delays.
> There should be no performance problem when scrolling the ListBox, it is
> oblivious to where the widgets are coming from.  With custom ListWalker
> classes you do need to think about this though, because you can
> introduce delays with long calculations in get_next or get_prev.  The
> browse.py program has this problem when it reads directories for the
> first time.  Ideally it should create a temporary "Loading..." widget
> and replace it when done loading and sorting.
> Ian
> * python gets a bad reputation because of programmers that don't think
> about this when working with huge data structures, for example old
> versions of "yum"
> _______________________________________________
> Urwid mailing list
> Urwid at lists.excess.org
> http://lists.excess.org/mailman/listinfo/urwid

More information about the Urwid mailing list