On Mar 30, 11:17 am, Steven D'Aprano <st...@remove-this- cybersource.com.au> wrote: > On Mon, 30 Mar 2009 06:40:00 -0700, jfager wrote: > > I've written a short post on including support for configuration down at > > the language level, including a small preliminary half-functional > > example of what this might look like in Python, available at > >http://jasonfager.com/?p=440. > > > The basic idea is that a language could offer syntactic support for > > declaring configurable points in the program. > > What's a configuration point? Where do I find them in my programs?
A configuration point is what you create when you use this proposed feature. You find them in your programs wherever you (or whoever wrote them) defined them. > > The language system would > > then offer an api to allow the end user to discover a programs > > configuration service, as well as a general api for providing > > configuration values. > > Why is an end user changing variables in my program? Because you used this construct to tell them they could. It's not a hook for every variable, just the ones you want to expose. > > The included example implements the first bit and hints at the third, > > defining a function that looks up what variable its output will be > > assigned to and tries to find a corresponding value from a configuration > > source. It's very preliminary, but I hope it gives a flavor of the > > general idea. > > Not really. It would help if you explained what problem you are trying to > solve, what people do now, and how what you suggest would make that > easier. It's the configuration problem. Right now you would use something like ConfigParser or optparse to populate some configuration object, which you would then pass around and extract values from. This would provide two advantages over these approaches: it would separate "what can be configured" from "the mechanism by which it is configured" - i.e., I, programmer, don't have to make a decision about what the end user has to do to give me those values. And it would allow the configurable surface of the program to be discoverable; I wouldn't have to poke through code or documentation that was maintained separate from the source code. > Having read your blog post, I'm going to take a wild stab at guessing > what you mean: > > * Programs often have variables which relate to user-configurable > options. For example, a basic list files command might include something > like this: > > if sys.argv[1] == '-l': > show_long_listing = True > else: > show_long_listing = False > # ... > # much later... > for filename in directory(): > if show_long_listing: > print "%s %s %s" % (permissions(), filename, date()) > else: > print filename > > * The current solution is for the program author to define the interface > and the implementation separately. For example, in the above code > snippet, the command line option '-l' is the interface available to the > end user, while the variable show_long_listing is the implementation used > to implement configuration options in the program. > > * You propose to expose the variable show_long_listing and it's ilk > directly to the user, presumable via some service which can interrogate > the program, discover what "configuration variables" are available, and > allow the user to stuff random values into them in the hope of getting > new and exciting bugs^W behaviour. What, exactly, is preventing them from stuffing random values into them now? The boilerplate of manually reading the param from the command line and assigning it to a variable makes things magically safe? If you'll notice in the example code, there's an optional parameter to process whatever argument is passed in; that's where any safety checks can be performed. > * This is better than current solutions to the question of getting > configuration options from the user, like getopt and similar, because... ? Because it means the developer doesn't have to know or care how the end-user ultimately inserts configured values. Because it provides a unified mechanism for all configuration instead of a hodge-podge of different techniques for what is ultimately the same basic task. Because it lets you quickly make a parameter of a program configurable (or not) without having to rearchitect the application. > * This would be better with syntactic support rather than a library or > module because... ? Because a big part of this is the discovery of these endpoints, which seems like it would best be handled at a lower level than a library can currently provide. Because finding what variable you're assigning to currently requires querying the bytecode. Because libraries inevitably introduce boilerplate that can simply be avoided if its a language feature. Because the requirement is broad enough and similar enough across concerns to be provided as a basic service. - Jason -- http://mail.python.org/mailman/listinfo/python-list
