[Twisted-Python] config interface

Glyph Lefkowitz glyph at twistedmatrix.com
Wed Apr 11 12:31:12 EDT 2001

On Wednesday 11 April 2001 10:42, you wrote:

> > That trick is a necessary addition to the API in any case -- these
> > functions aren't enough.  However, you might want to have
> > ConfigurableDictionary, ConfigurableItem, and ConfigurableSequence types
> > which have different ideas about how things get added to them.
> I don't understand what those methods should do. Could you explain a bit
> more?

class Configurable
class ConfigurableDict(UserDict.UserDict, Configurable)
class ConfigurableSequence(UserList.UserList, Configurable)

Rather than adding a whole new interface (configAddItem etc) why not just use 
the built-in list/dictionary interfaces for the two kinds of collection you 

> The main thing I was confused about was what exact paramaters might
> configAddItem and configRemoveItem need. Not all containers will have an
> 'id' for each of their children, but I suppose they could be somehow
> generated. For instance, for Selector, I was starting to implement the ids
> for each server as 'str(serverObj)', but this didn't seem very nice to me.
> I guess now that I think of it again, it doesn't seem all that bad. I might
> need to add id(Obj) onto that, though, in some cases.

I don't really understand why this is relevant; why would you need IDs for 
servers?  Aren't they just added in some order (a list)?

> > Also, what are you planning on doing for configuring an object's
> > attributes? It seems like that should behave differently from configuring
> > the objects it contains.
> I already have that implemented. Remember config_strings and
> config_callbacks?

I'm still not 100% comfortable with that implementation, but I suppose it can 
be refactored later.

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m

More information about the Twisted-Python mailing list