[PEAK] Does a PEAK-ized webware esist ?

[Phillip J. Eby]

At 04:04 PM 1/30/04 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 05:33 PM 1/29/04 -0600, Ian Bicking wrote:
>>
>>>* When option values are retrieved, type information is given.  So 
>>>there's no configuration schema.
>>
>>FWIW, PEAK offers both .ini files (that use Python expressions and are 
>>therefore dynamically typed) and ZConfig (which is schema-driven).
>
>These configuration files don't use Python expressions, so they are 
>somewhat different.  I suppose there's an implicit schema built into the 
>code itself, as types are specified when fetching the configuration 
>information.

Yeah, I considered that in early work on PEAK's .inis, but rejected it 
because it was too awkward in code, *and* it bound code to 
configuration.  In PEAK, configuration can be supplied several different 
ways, so encoding a serialization at the point of use goes counter to the 
point.  We want to be able to say:

     something = binding.Obtain(PropertyName('foo.bar.baz'), 
adaptTo=ISomethingOrOther)

without encoding the actual concrete type that will be supplied, or how it 
gets there.


>This might be annoying later on, I'm not sure -- but it makes adding new 
>configuration parameters very easy.

It got very annoying very quickly for me, but of course that's because 
peak.config isn't fundamentally oriented towards configuration files, but 
towards providing access to configuration -- a very different thing.


>If I was going to use Python expressions, I'd probably use a Python module 
>as the configuration source and forget about .ini (grabbing __dict__'s as 
>necessary).  The only problem is introducing sectional structure.  Using 
>class: is one way, but that use of class is a bit of a misnomer.

Python modules are also sequential and imperative code.  PEAK's .ini files 
are mostly non-sequential, declarative, and lazy.  Expressions in an .ini 
file are eval()'d when you request the information, not when you read the 
configuration file.  This makes them potentially much faster to load than 
Python modules, because no actual parsing takes place at read time.  And 
expensive objects like database connections aren't created until -- and 
unless -- they're needed.


>I guess if I wanted a typed configuration syntax, YAML seems like a 
>reasonable option.

We considered it for a while.  The problem is that YAML isn't really a 
configuration format.  It's a serialization format that just happens to be 
very human-readable.  But it's not very human-editable or human-creatable, 
even for programmers.  By contrast, Python expressions that produce 
equivalent values are actually (IMO) *more* readable than YAML, at least 
for a Python programmer.

Of course, there's nothing at all stopping one from adding YAML reading to 
peak.config, since as you say it's a typed format.