Re: [Configobj-develop] String Substitution

[Fuzzyman <fuz...@vo...>]

Rick Kier wrote:

>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 = "one"
>RM> second = "$first plus one"
>RM> third = "$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 = "one"
>RM> second = "$first plus one" -- immediately evaluated to yield "one plus one"
>RM> third = "$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 = "$second plus one"
>RM> second = "$first plus one"
>RM> first = "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
>  
>
I don't use string substitution at all, so I am willing to listen to the
views of users on this.

It could theoretically break behaviour for others.

Anyone else got opinions ?

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

>Cheers,
>
>TeamSTARS
>  Dick Gordon and Rick Kier
>  
>RM> [my_program]
>RM> path = /home/rmunn/foo
>RM> configfile = ${path}/bar.txt
>
>RM> Instead, I have to do:
>
>RM> [DEFAULT]
>RM> path = /home/rmunn/foo
>
>RM> [my_program]
>RM> configfile = ${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.
>
>
>
>
>
>_______________________________________________
>Configobj-develop mailing list
>Con...@li...
>https://lists.sourceforge.net/lists/listinfo/configobj-develop
>
>  
>