[Twisted-Python] config interface
carmstro at dynup.net
Wed Apr 11 15:10:07 EDT 2001
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
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.
Chris Armstrong carmstro at twistedmatrix.com
http://twistedmatrix.com/~carmstro carmstro at dynup.net
More information about the Twisted-Python