[Twisted-Python] config interface
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
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
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