On Mar 31, 3:40 am, Steven D'Aprano <ste...@remove.this.cybersource.com.au> wrote: > On Mon, 30 Mar 2009 23:06:50 -0700, jfager wrote: > > On Mar 30, 9:31 pm, "Rhodri James" <rho...@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.
No, not at all. I'm saying that the programmer shouldn't have to care what the end-user's interface is, not there's no end-user interface at all. For the program 'ls', why should I, the programmer, care at all how the end user actually specifies that they want 'long options'? I might think or know that a command line argument is the 'best' way, but why should I even worry about it? I should just tell them that option exists, and then they can choose how to give me a value for it in whatever way they please. > 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". Not at all, not even a little bit. Why wouldn't you just say some variable 'long-lines' is configurable, and then use that to do all the work you would have done by manually parsing the command-line arguments for the -l flag? You, the programmer, still have complete control over what is or isn't visible to the end user, it's not like I'm advocating that every variable in the system automagically become end-user configurable without programmer input. > I don't think that's going to fly. Separation of interface and > implementation is a Good Thing. Agreed, that's the whole point of this. Use the interface provided by the language, then let the end user provide their own implementation (of course, there will be basic ones provided out of the box) of how to specify their configuration values. > > 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() > #... This second one is what I intended (no optionlist param needed, though). I'm curious - why do you think this is a bad thing? One toy example looks pretty similar to how you would do things now, and you're ready to throw out the whole concept? Notice that you did actually gain something that I think is significant - you no longer have any hardcoded reference to the fact that make_long_list is defined as a command line parameter. > > > 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. Keep throwing out examples of where this makes things more complicated, it's good to work through all the concerns. > >> 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. If that's true, it's because the developer consciously said at some point, "This needs to be configurable". And I, as an occasional end user of software products, would sometimes love to find I could modify variables I didn't even know existed. Discoverability is a good thing, much better than having a potentially useful knob hidden away behind stale documentation or buried deep in source code somewhere. > > 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. I don't know what to say to this, except that it seems like the penalty for missing something in the discovery phase of what I'm proposing would be either less dangerous or more obvious, less dangerous because the program would just fall back to a default and continue on (you didn't come across some variable you didn't even know existed), more obvious because you might be expecting to be able to configure something specific, or because possibly no value would be provided and an error would be thrown. - Jason > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
