[Twisted-Python] Configuration: The Never Ending Story.

Moshe Zadka moshez at zadka.site.co.il
Fri May 11 12:49:17 EDT 2001

On Fri, 11 May 2001 19:36:24 +0300, Chris Armstrong <carmstro at dynup.net> wrote:

<snipped agreement on the axioms>

> > .getAnswer(name, answer) --> notify the application that an answer has been
> >                              given to a particular question
> >                              It can throw an InvalidAnswer exception with
> >                              a string for a reason. This is for 
> >                              application-level verification, and is discouraged.
> name change: setParamaters()

setParameter() sans the 's'. One call per parameter

> > .endAnswer() --> the "application" promises that no methods of the object
> >                  will be called between a series of .getAnswer()s and 
> >                  .endAnswer(). So, this means that if the UI got a bunch 
> >                  of answers, it will call .getAnswer() several times, and
> >                  then .endAnswer(). The UI will *check* for this method's
> >                  existance, and will not call it if it doesn't exist.
> name change: i'm not sure what, but endAnswer doesn't sound right.
> What this is for is deferred calculation of answers. the not-calling-methods
> thing needs to be thought about, so we don't have some weird bugs where TPy
> goes completely haywire while configuring. (For instance, what if we're
> configuring a web server through the web interface?)

That's the classical example for why it's needed. Since the UI should
do something like that

for parameter in stuff_i_got:

Then everything is fine.
That's a classical case of "if there's a doubt, there isn't a doubt": if the
UI is *not* sure it won't call other methods, it *should* call .endParameters()
It is *not* promised that there won't be multiple batches -- that's a QoI

> name change: [from .hasAnswer to] hasValue()?

Yep, definitely

> > Objects which can be created by the UI should have an __init__ which
> > can be called without arguments. If there is any initialization which
> > requires arguments, it should be done in endAnswer(). The UI also promises
> > not to call .endAnswer() for an object if there any questions which have
> > not been answered and do not have a default (.hasAnswer is false.)
> Ok, instead of __init__s that don't take arguments, we have klass.getInitArgs()
> that is another set of questions that the user answers before the UI
> instantiates the object (well, it'll have to be klass.__dict__['getInitArgs'](),
> as glyph pointed out to me). 

No, we won't.
We'll have copy.copy(klass.initParameters). No need to make it a callable,

> Also, when we instantiate the object, we call
> newObject.setParent(parent), as moshe talks about in the open questions at
> the bottom of his mail.

> name change for all of the following: *Parameter


> > 
> > class BooleanQuestion:
> > class IntQuestion: (can have .min and .max)
> > class FloatQuestion:
> > class StringQuestion: (can have .maxlength)
> > class LongStringQuestion: (same as above -- it's a hint to the ui)
> > class InterfaceQuestion: (specify interface, valid answers are objects)
> > class ArrayQuestion: (an array of the same kind of question)
> moshe told me this was a thinko, so forget about array of questions :)

I misunderstood radix. Let me clarify:
It's something like if you want to have a set of Servers in a selector:


> > class DictQuestion: (a dictionary mapping strings -> same kind of question)
> I don't really get this one.

Think of a web Resource which is a folder.

Then you can have

{'children': DictParameter(InterfaceParameter(WebResourceInterface)) }

[re __implements__]
> I seem to remember some standardization of this that was proposed in a PEP.
> Maybe we should use that standard for now, but of course just use our own
> implementation of the implementation-checking stuff. (tongue twister, eh?)

Python will not have *any* implementation of interface checking stuff.
Of course, we'll just take objects up on their __implements__ word,
not check through methods.

> > * How do we allow the object to signify groupings of questions?
> >   Suggestion: this means the design is bad -- break down the object
> >   into smaller objects
> I'm not sure of my stance on this. I'll try to think of some examples and
> discuss.
I myself have misgivings on that. But maybe we can punt on it for now?
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez at debian.org  |http://www.{python,debian,gnu}.org

More information about the Twisted-Python mailing list