Re: [Configobj-develop] String Substitution

[Robin M. <rob...@gm...>]

Following up on my own post:

On 6/7/06, Robin Munn <rob...@gm...> wrote:
> Summary: I propose eager evaluation of interpolated values, with
> lexical scoping for finding values. The original, non-interpolated
> strings should be saved for the purposes of configfile round-tripping
> and, optionally, post-evaluation propagation of changes to dependent
> values (e.g., changing the value of "bar = $foo" when "foo" is
> modified).

I started to try to implement the above in code, and ran into enough
problems that it made me realize that this is a bad idea, and that the
author of the above proposal is clearly an idiot. ;-)

There's nothing wrong with lazy-loading. The *proper* way to do it, in
fact, is to lazy-load the values we find, *recursively*, in a classic
depth-first algorithm. (Keeping track of our backtrail, to catch any
infinite loops). Thus:

foo = 123
bar = $foo
baz = $$foo
quux = $bar + $baz

Finding the final value of "quux":
1) Interpolate $bar
1a) Interpolate $foo
1a1) Find value "123"
1b) Final value of bar is "123"
2) Value of quux now "123 + $baz". Interpolate $baz
2a) Interpolate $$foo
2b) Final value of baz is "$foo"
3) Final value of quux is "123 + $foo".

The original (non-interpolated) values are left in the Section dict at
all times, so that every time they're loaded, they will be
re-interpolated anew. This allows for "foo" to be changed, and the
values of "bar" and "quux" to automatically be re-computed next time
they're accessed. (But not "baz", since it doesn't depend on the value
of "foo").

This will be a lot easier to implement in code than my previous
proposal, since it requires fewer changes to what's already there.
I'll make two patches: one with the current which-section-to-look-at
behavior (only looking at sections named DEFAULT), and another with my
preferred look-at-all-parent-sections behavior.

-- 
Robin Munn
Rob...@gm...
GPG key 0xD6497014