[Twisted-Python] config interface

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


On Sunday 08 April 2001 20:04, you wrote:
> configurable objects are organized in a tree. Every object defines these
> methods:

>     #ContainableTypes should return a list of classes that
>     #it can hold.
>     def configContainableTypes(self): pass

This seems fine...

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

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

>     #AddItem should add a child to this object
>     def configAddItem(self, id, item): pass

Also fine...

>     #RemoveItem should remove a child from this object.
>     def configRemoveItem(self, id): pass

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


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 
list of types/classes of the required arguments, in order, and the second is 
a hash of name:type/class of optional argument.

These arguments get filled in by your configuration interface code, and 
passed to:

def configCheckInitArgs(self, args, kw)

This to separate preconditions of the init from the init itself -- if this 
indicates there's something wrong with the arguments (for example, an integer 
is outside of its acceptable range) then this message can be displayed to the 
user for them to try again.

def configDoInit(self, args, kw)

This will most likely be a passthru to self.__init__, probably frequently 
enough to make that the default implementation, but since 
configGetRequiredInitArgs may want to do some pre-initialization, things 
could be different.


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.

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.


-- 
                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph





More information about the Twisted-Python mailing list