Re: [Configobj-develop] ANN: ConfigObj 4.7.2 Release

[Michael F. <fuz...@vo...>]

On 04/03/2010 15:17, David Hostetler wrote:
>
>
> On Tue, Mar 2, 2010 at 10:23, Michael Foord <fuz...@vo... 
> <mailto:fuz...@vo...>> wrote:
>
>
>     * BUGFIX: Members that were lists were being returned as copies due to
>        interpolation introduced in 4.7. Lists are now only copies if
>     interpolation
>        changes a list member. (See below.)
>
>
>     For general information on string interpolation in ConfigObj see:
>     http://www.voidspace.org.uk/python/configobj.html#string-interpolation
>
>     Since version 4.7 string interpolation is done on string members
>     of list values. If interpolation changes any members of the list
>     then what you get back is a /copy/ of the list rather than the
>     original list.
>
>     This makes fetching list values slightly slower when interpolation
>     is on, it also means that if you mutate the list changes won't be
>     reflected in the original list:
>
>     >>>  c  =  ConfigObj()
>     >>>  c['foo']  =  'boo'
>     >>>  c['bar']  =  ['%(foo)s']
>     >>>  c['bar']
>     ['boo']
>     >>>  c['bar'].append('fish')
>     >>>  c['bar']
>     ['boo']
>          
>
>     Instead of mutating the list you must create a new list and
>     reassign it.
>
>
> Hey Michael,
>
> I have some concern over this behavior.  Namely, the inconsistency 
> bothers me.  I don't like that the programmer now needs to know the 
> nature of a string value for a given list option in order to be able 
> to interact with it correctly.  Because the string's value *changes* 
> the behavior.
>
> It feels sort of like if I were to need to know the value of an 
> integer in order to know how to use it in a mathematical expression.  
> a+b would work for certain integer values of b, but would need to 
> become a+int(str(b)[:]) for other integer values of b.  Yuk.
>
> One of the most powerful things about ConfigObj is that it insulates 
> program logic from needing a priori knowledge of input data.  I feel 
> like this new list interpolation behavior violates that.  As  
> programmer, I shouldn't ever care, know, or need to know, whether or 
> not the person who is providing input data elected to have one piece 
> of data substituted via reference with the value of another, before 
> it's ever given to me.  Interpolation of input data is something that 
> is done outside of the purview of the program consuming the input 
> data.  Value substitution provided by interpolation is a convenience 
> mechanism for the data provider, and using it or not using it 
> shouldn't alter the consumer's interface for ConfigObj.
>
> As it stands, the choice to use or not use list interpolation ripples 
> over into the other side.  I think any program consuming list data 
> provided by ConfigObj will have to (or should) treat it as always 
> immutable.  In other words -- I'll pretend that all lists are of the 
> interpolated variety (copies) since I can't be sure when they are and 
> when they aren't, and it's much safer to make this assumption than it 
> is to assume the opposite.
>
> Thoughts?
>

Well, it bothers me too - but interpolation in lists was already 
released, so the question was whether or not to pull the feature or fix 
the problem. 4.7.2 was a quick bugfix release and I'm certainly willing 
to consider how we handle this for 4.8.

I can understand that if you have interpolation on and use list values 
you can no longer guarantee that mutating a list will work. Reassigning 
the list will always work, but that may wipe out the underlying 
interoplation values and so is not ideal. In this regard 4.7 was 
backwards incompatible with previous releases, but this was an unforseen 
consequence not a deliberate intention. If we change it again in 4.8 it 
will be another backwards incompatible release. *sigh*

One option would be to have list interpolation off by default with (yet 
another) keyword argument to switch it on. That way you only have to 
worry about it if you have enabled the feature.

Thoughts?

Michael

>
> As always - thanks for your hard work!
>
>
> regards,
>
> -David
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.