Thoughts on language-level configuration support?

[Steven D'Aprano]

On Mon, 30 Mar 2009 23:06:50 -0700, jfager wrote:

> On Mar 30, 9:31 pm, "Rhodri James" <rho... at wildebst.demon.co.uk> wrote:
...
>> This would be a interesting idea, but ultimately no more than a veneer
>> over the current set of configuration possibilities.  Quite how such a
>> system would tell whether to get configuration data from command line
>> parameters, a config file somewhere, or just pull bytes off the Z-wave
>>  from Mars, I'm not at all clear.
> 
> Not a veneer over; a foundation under.  As I acknowledged in my blog
> post, this would require a small bit of bootstrapping, to configure
> which end-user configuration system was used.  But this would simply
> point to an adapter, that would map from the desired configuration
> interface into the canonical standard api provided by the language
> system.

Let's talk about a practical example. The ls command has the API that the 
"-l" switch means "show me long options". You're suggesting that users 
should not interact with the user-interface, but directly with the 
implementation. You are, essentially, assuming that there is a one-to-one 
correspondence between data that the user inputs and variables in the 
implementation, and that users can understand the implementation.

But that's not necessarily the case. The switch -l might affect a dozen 
different variables. So instead of the user needing to learn *one* 
command line option (or click on one checkbox in a GUI, or whatever), you 
expect him to reason "I want to see a long display of my files, so I need 
to set the value of line_width to 47, date_style to 3, show_perms to 
True, and format_into_columns to -1".

I don't think that's going to fly. Separation of interface and 
implementation is a Good Thing.


Or consider another scenario:

def ls:
    if '-l' in sys.argv:
        file_iterator = SimpleFilenameWriter()
    else:
        file_iterator = DetailedFilenameWriter()
    #...


Under your proposal, the user would somehow have to create the 
appropriate instance and feed it to your program. That's simply not 
practical! So you still need some sort of proxy variable, virtually 
identically as you do now:


conf make_long_list = True

def ls(optionlist):
    if make_long_list:
        file_iterator = SimpleFilenameWriter()
    else:
        file_iterator = DetailedFilenameWriter()
    #...



> The problem with the current set of configuration possibilities is that
> there's nothing really constant between them, unless the programmer
> explicitly codes it, even though they're basically accomplishing the
> same thing.  There's nothing amazingly special about this proposal, it's
> just saying:  that basic thing that we do in a lot of different ways,
> let's make as much of that as possible standard.

Over-generalization actually makes things more complicated. I think 
you're over-generalizing.


...
>> You've just specified a different way in which you have to do this, one
>> that's a good deal less visible in the code
> 
> Why would it be less visible?  If it's syntax, you would know exactly
> where it was just by looking.

It could be *anywhere* in your project. It could be in some random 
library that you imported, and the user discovers that they can modify 
variables you didn't even know existed.


> Actually, you get the best of both worlds.  You get to see clearly in
> the code how the configured values are actually used, and you get the
> gathered summary of configurable values from the "discoverability"
> implementation.

I've learned to distrust "discovery", ever since I learned that my 
doctests, which were supposedly all running without error, in fact hadn't 
been discovered at all, and not one single test was running. So even if 
you could get this working, I'd be luke-warm on the idea.



-- 
Steven