Re: [Configobj-develop] Simpler interpolation using PEP 292 $templates

[Rick K. <ri...@mc...>]

Hi Robin et all,

Monday, June 05, 2006, you wrote:

RM> On 5/23/06, Fuzzyman <fuz...@vo...> wrote:
>> Hmmm... on the other hand I'm not convinced recursive interpolation is
>> used by anyone. I don't mind it being dropped for the string templating
>> interpolation - *if* that makes it any easier.

RM> Seeing your blog post (where you mention that PEP-292-style substition
RM> will be going into the next ConfigObj release) got me thinking about
RM> recursive interpolation again. Right now the way it works is as
RM> follows:

RM> first =3D "one"
RM> second =3D "$first plus one"
RM> third =3D "$second plus one"

RM> "third" is evaluated, yielding "$second plus one" -- which is then
RM> further evaluated to yield "one plus one plus one". This is "lazy"
RM> evaluation -- each string is only evaluated once its value is
RM> requested.

RM> What if this was changed to use "eager" evaluation instead, where each
RM> string is evaluated as it goes past?

RM> first =3D "one"
RM> second =3D "$first plus one" -- immediately evaluated to yield "one plu=
s one"
RM> third =3D "$second plus one" -- immediately evaluated to yield "one plus
RM> one plus one" (in one single step, since the value of $second is now
RM> "one plus one" which needs no further recursive evaluation)

RM> The advantage of lazy loading is that no particular order is enforced
RM> on values. We could have written it in the order:

RM> third =3D "$second plus one"
RM> second =3D "$first plus one"
RM> first =3D "one"

RM> And it would have worked. That ordering would cause an error under
RM> eager-evaluation, because "$second" is as yet undefined when "third"
RM> is being created.


RM> There's one other behavior of the interpolation that was surprising to
RM> me: the fact that interpolated variables are *only* allowed to refer
RM> to values in the [DEFAULT] section. That means that I can't do:

Agree 100% on this.

We don't use interpolation due to the current behavior

Cheers,

TeamSTARS
  Dick Gordon and Rick Kier
 =20
RM> [my_program]
RM> path =3D /home/rmunn/foo
RM> configfile =3D ${path}/bar.txt

RM> Instead, I have to do:

RM> [DEFAULT]
RM> path =3D /home/rmunn/foo

RM> [my_program]
RM> configfile =3D ${path}/bar.txt

RM> This, IMHO, breaks the Principle of Least Surprise. This may be how
RM> ConfigParser behaves, but is this behavior correct? I would suggest
RM> that it isn't; that people writing config files are much more likely
RM> to naturally write the first form than the second.

RM> This may be two separate issues, though, so perhaps I should break the
RM> second one out into its own thread.