[Urwid] possible bug: AttrMap does not pass function calls/property lookups to the wrapped widget

Ian Ward ian at excess.org
Mon Feb 17 12:36:02 EST 2014


On Mon, Feb 17, 2014 at 10:04 AM, Vlad <vlad at demoninsight.com> wrote:
> Over the course of building this app I noticed something that might be a bug
> or "user error":
>
> - contrary to the documentation, AttrMap does not appear to forward method
> calls to 'w', the wrapped widget.

Oh, you're absolutely right. There is a bug in the documentation.

I decided that it was a mistake for AttrWrap to pass all attribute
access and method calls to the wrapped class and I deliberately did
not include that feature in AttrMap. It seems I forgot to update the
docstring.

There are many type of decoration widgets in Urwid. If we pass through
attribute access for just one decoration, why not do it for all
decorations? If we do it for all decorations then users will be able
to mostly pretend the decorations aren't there, but that could lead to
some really hard to understand code. It mixes the namespace of every
decoration with the base widget's namespace.

> I find AttrMap to be a very useful design concept. But I think it falls
> short of its intended purpose because I find myself constantly needing to
> insert .base_widget in various places -- AttrMap is not as transparent as the
> docs suggest. A piece of urwid code will work but later break when you add
> an extra AttrMap layer somewhere. Note that using AttrWrap instead makes the
> example above work -- even though AttrWrap is deprecated in favor of AttrMap.
> Several stock urwid examples also break if AttrWrap is replaced with
> AttrMap, and it originally took me a few hours to figure out why.

I agree that it should be easier to work with decoration widgets. The
best idea I have at the moment is to add a 'decorations' property or
'get_decorations()' method to widgets that will be called whenever
that widget is added to a container or assigned to loop.widget. This
way a widget class can define all its own decorations but still
present just its methods and attributes to the programmer.

How does that approach sound to you?

Ian



More information about the Urwid mailing list