Robin Becker <ro...@reportlab.com> writes: > For the specific case of the canvas_basefontname I don't actually need > to do anything specific since it is just a string
The configuration values should be nothing but immutable values: strings, integers, booleans. Possibly collections of those. You seem to be implying that some configuration values are complex objects; that's undesirable. You seem to be further implying that configuration is executable code; that is *definitely* undesirable (look at the awful mess created by making Distutils configuration an executable program). > however, before it can be used in action support has to be provided ie > I must register the font used. That's fine, it is a step that should come *after* configuration is entirely completed and the static values are known. > I could just make the few usages of this value check for callability > at use time, but that would scatter the problem; if one default is > special why not all. Indeed. The correct solution is not to make configuration executable, but instead make it static data, read by the program as simple immutable values. > Effectively the defaults setup is not complex enough to allow use of > itself; that must be a fairly common problem. The common solution is: * Use a non-executable configuration file format. ‘configparser’ from the standard library is a good option, YAML is another. * Use the conventional precedence order for applying configuration values: default values, overridden by config files, overridden by environment variables, overridden by command-line options. * Only after configuration using the above precedence is complete, use the immutable values defined to change program behaviour (e.g. create or modify dynamic, complex objects that respond to the config options). If you've got a config file that is executable, and attempts to define program objects, then yes you're going to get the complex mess you describe in your initial posting of this thread. Avoid that by migrating away from such a poor configuration format: Switch to a ‘configparser’ format, or some other static, non-executable data file. > Probably the correct thing to do was always to use an object to hold > the defaults. Yes, a ‘configparser.ConfigParser()’ instance can store defaults which will be over-ridden by the sequence of configuration files read. -- \ “I do not believe in forgiveness as it is preached by the | `\ church. We do not need the forgiveness of God, but of each | _o__) other and of ourselves.” —Robert G. Ingersoll | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list