instance as module

[Ben Finney]

Robin Becker <robin at 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