Thoughts on language-level configuration support?

jfager jfager at gmail.com
Wed Apr 1 23:13:54 EDT 2009


On Apr 1, 8:56 pm, CTO <debat... at gmail.com> wrote:
> > I just mean that there should be a
> > clear and easy way to do it, that it should be considered a basic
> > service, and that if the best way to satisfy all the goals is to
> > integrate it directly into the language, that shouldn't be shied away
> > from.
>
> Honestly, the programming language and the configuration languages
> should never, ever, ever be inseparable. I don't see a reason for
> it and I see some great reasons not to do it.

I'm not saying the actual end-user configuration language would be
tied to the programming language.  I'm starting to think a better way
to describe this is to play down configuration as a use case, and
instead focus on what the actual mechanism is:  a way to define points
in your program that can have values injected into them at runtime by
some external entity, a uniform naming scheme for those points derived
from the code, and a way to expose those points to interested
consumers.


> > The example that I have on my blog post, I consider that 'syntax',
> > even though it's implemented as a function, mainly just because it
> > digs into the bytecode and modifies the normal way a function is
> > evaluated (the function's value is determined by where the output
> > would go).
>
> I don't particularly see why this is needed.

It was a stab at the 'uniform naming scheme' - the function fetches a
config value based on a key derived from the name of the variable its
output will be assigned to.  It definitely needs more thought, but at
least I got to play around with the bytecode tools :)


> To my mind the strongest
> argument you are making, by far, is the "discoverable" argument. If
> you were able to build a system which permitted other components to
> discover configuration options and give configurable levels of
> permanence and visibility to them, that would be great. If you were
> able to do it and make it easy for a programmer to interact with, you
> would most definitely have a module I would use. But I daresay you're
> going to have to build it (or at least mock it up) before you're going
> to get a lot of folks jumping on the bandwagon, and its a *long* slog
> before you hit the level of support and stability you're going to need
> to convince folks to trust their precious config files to it.

Agreed, and I do intend to do a proper mockup when I get the time; I
just wanted to get some initial reactions.  Thanks for your feedback.




More information about the Python-list mailing list