[Twisted-Python] config interface

Chris Armstrong carmstro at dynup.net
Wed Apr 11 11:42:20 EDT 2001

On Wed, Apr 11, 2001 at 06:31:32AM -0500, Glyph Lefkowitz wrote:
> >     #Type should return the type of the current object
> >     def configType(self): pass
> I don't think this is necessary though.  Can't you just use the Python class?

You're right. I was switching to classes for the type system, anyway.

> >     #GetContents should return a dict of children of this object. {"name":
> > obj} def configGetChildren(self): pass
> Seems like a list of tuples (.items() style) might be more appropriate than a 
> dict, considering that this really isn't mutable.

Ok, makes sense.

> > I'd like to change this API somewhat to allow different paramaters to add
> > and remove item methods. Not all objects need ids to add an object, and
> > it's not natural for some objects to represent their contents as a dict
> > (selectors, for instance). I was thinking about a solution similar to the
> > improper-state trick that glyph described to me, only it would just look at
> > the arguments that a method needs rather than a constructor of a class.
> 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

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.

The following you described to me on IRC, but I appreciate you organizing
it for my benefit. :)

> In order for new configurable things to be instantiatable, you'll need API 
> additions like:
> def configGetRequiredInitArgs(self)
> This returns a 2-tuple of a sequence and a hash.  The first sequence is a 
> Note that if something returned by configGetRequiredInitArgs is a class, that 
> class be configurable as well -- that, and your interface may need to be 
> somewhat recursive in order to allow you to pass configurable elements to the 
> initializers of other configurable elements... I'd recommend trying to get 
> something work only supporting basic types at first.

That sounds pretty neat. Recursion is such fun. :)

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

Thanks for the reply
Chris Armstrong                        carmstro at twistedmatrix.com
http://twistedmatrix.com/~carmstro     carmstro at dynup.net

More information about the Twisted-Python mailing list