[Twisted-Python] config interface

[Chris Armstrong]

On Wed, Apr 11, 2001 at 11:31:12AM -0500, Glyph Lefkowitz wrote:
> > 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 
> have?

Ok, I get you know. Good idea. :)

> 
> > 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)?

Exactly, servers really don't have IDs. But other things do. That's why I was
confused in the first place. But it is useful to have them for the UI.
str(serverObj) may not be that user friendly, but it has to be unique.
Also the ID is needed for deleting things from the selector.

Now that I think of it, with your dict and list overriding ideas, I don't
think IDs would even be needed. Or maybe they would. I'll work on it. :)

> > 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.

Okie dokie.
-- 
Chris Armstrong                        carmstro at twistedmatrix.com
http://twistedmatrix.com/~carmstro     carmstro at dynup.net