configobj-develop — Support and development of ConfigObj

Re: [Configobj-develop] DVCS?

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

On 04/03/2010 15:59, Jason Baker wrote:
> On Thu, Mar 4, 2010 at 9:52 AM, Michael Foord 
> <fuz...@vo... <mailto:fuz...@vo...>> wrote:
>
>     On 04/03/2010 14:45, Jason Baker wrote:
>>     Has anybody thought about switching ConfigObj to a DVCS?  The
>>     main reason why I ask is because they make contributing to open
>>     source projects *so* much easier.  Instead of making a patch,
>>     putting it in a ticket, and then having someone apply it, all you
>>     have to do is open a ticket saying "pull this commit from my
>>     repository" and then have the branch owner pull it.
>>
>>     I personally am partial to git, but hg and bzr are both good
>>     choices (I believe Google Code has support for hg).
>     Well, I'm a big fan of Hg (git not so much). I doubt I'll switch
>     ConfigObj over in the forseeable future though, not unless / until
>     there are more committers which doesn't seem immediately likely.
>
>
> I think this is a reasonable stand to take.  But let me play devil's 
> advocate.  My point is that using a DVCS would make it easier for 
> people to contribute.  Isn't this kind of a chicken-and-the-egg type 
> problem?  After all, you want to get more people to contribute before 
> moving to a DVCS, but moving to a DVCS is a good way to get more 
> people to contribute.
>
> (I'm not trying to prod you into using a DVCS.  I just want to make 
> sure you've thought this out fully.)

Well - you can already use Hg to talk to svn, and generating a patch 
from a set of diffs is a single command.

svn is *still* much more popular than DVCS (the gap is narrowing but svn 
has a big lead), so I think switching is actually likely to *reduce* the 
number of people able to contribute in the short term.

Most of the patches that have ever been contributed to ConfigObj have 
required reworking (there are exceptions - the entire interpolation 
engine system was an outside contribution), so I'm not sure that the 
ability to pull is even that useful in *practise* (for configobj 
specifically - not as a general statement). It is also useful to have 
contributions tracked on the issue tracker as I deal with them 
sporadically. Centralised systems also have their advantages. :-)

Michael

>
> ------------------------------------------------------------------------------
> 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.

Re: [Configobj-develop] DVCS?

[Jason B. <jb...@ze...>]

On Thu, Mar 4, 2010 at 9:52 AM, Michael Foord <fuz...@vo...>wrote:

>  On 04/03/2010 14:45, Jason Baker wrote:
>
> Has anybody thought about switching ConfigObj to a DVCS?  The main reason
> why I ask is because they make contributing to open source projects *so*
> much easier.  Instead of making a patch, putting it in a ticket, and then
> having someone apply it, all you have to do is open a ticket saying "pull
> this commit from my repository" and then have the branch owner pull it.
>
> I personally am partial to git, but hg and bzr are both good choices (I
> believe Google Code has support for hg).
>
> Well, I'm a big fan of Hg (git not so much). I doubt I'll switch ConfigObj
> over in the forseeable future though, not unless / until there are more
> committers which doesn't seem immediately likely.
>

I think this is a reasonable stand to take.  But let me play devil's
advocate.  My point is that using a DVCS would make it easier for people to
contribute.  Isn't this kind of a chicken-and-the-egg type problem?  After
all, you want to get more people to contribute before moving to a DVCS, but
moving to a DVCS is a good way to get more people to contribute.

(I'm not trying to prod you into using a DVCS.  I just want to make sure
you've thought this out fully.)

Re: [Configobj-develop] DVCS?

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

On 04/03/2010 14:45, Jason Baker wrote:
> Has anybody thought about switching ConfigObj to a DVCS?  The main 
> reason why I ask is because they make contributing to open source 
> projects *so* much easier.  Instead of making a patch, putting it in a 
> ticket, and then having someone apply it, all you have to do is open a 
> ticket saying "pull this commit from my repository" and then have the 
> branch owner pull it.
>
> I personally am partial to git, but hg and bzr are both good choices 
> (I believe Google Code has support for hg).
Well, I'm a big fan of Hg (git not so much). I doubt I'll switch 
ConfigObj over in the forseeable future though, not unless / until there 
are more committers which doesn't seem immediately likely.

Michael

>
> ------------------------------------------------------------------------------
> Download Intel® 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.

[Configobj-develop] DVCS?

[Jason B. <jb...@ze...>]

Has anybody thought about switching ConfigObj to a DVCS?  The main reason
why I ask is because they make contributing to open source projects *so*
much easier.  Instead of making a patch, putting it in a ticket, and then
having someone apply it, all you have to do is open a ticket saying "pull
this commit from my repository" and then have the branch owner pull it.

I personally am partial to git, but hg and bzr are both good choices (I
believe Google Code has support for hg).

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

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

On 04/03/2010 15:45, Jason Baker wrote:
> On Thu, Mar 4, 2010 at 9:25 AM, Michael Foord 
> <fuz...@vo... <mailto:fuz...@vo...>> wrote:
>
>     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.
>
>
> If we end up requiring that lists be reassigned, why don't we just 
> make them tuples that must be reassigned every time or even <shameless 
> plug>pysistence PLists[1]</shameless plug>?  This way, there's little 
> confusion over whether or not you can make changes to a list and have 
> them be reflected automatically.

Hehe. Using lists instead of tuples is a feature - I'd rather lose 
interpolation in list values (which is really a very minor convenience 
feature) than switch to an immutable data structure. But thanks for the 
suggestion.

Michael Foord

>
> [1] http://packages.python.org/pysistence/pysistence/persistent_list.html
> -- 
> Jason Baker
> Developer
> ZeOmega
> 3010 Gaylord Parkway, Suite 210
> Frisco, TX 75034
> O:  214-618-9880  ext 8024
> jb...@Ze...
> www.ZeOmega.com <http://www.ZeOmega.com>
> Proven. Progressive. Partner.
>
>
> ------------------------------------------------------------------------------
> 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.

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

[Jason B. <jb...@ze...>]

On Thu, Mar 4, 2010 at 9:25 AM, Michael Foord <fuz...@vo...>wrote:

>  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.
>

If we end up requiring that lists be reassigned, why don't we just make them
tuples that must be reassigned every time or even <shameless plug>pysistence
PLists[1]</shameless plug>?  This way, there's little confusion over whether
or not you can make changes to a list and have them be reflected
automatically.

[1] http://packages.python.org/pysistence/pysistence/persistent_list.html
-- 
Jason Baker
Developer
ZeOmega
3010 Gaylord Parkway, Suite 210
Frisco, TX 75034
O:  214-618-9880  ext 8024
jb...@Ze...
www.ZeOmega.com
Proven. Progressive. Partner.

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

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

On 04/03/2010 15:25, Michael Foord wrote:
> 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.

To respond to this specifically - the problem is that interpolation of 
list values *requires* a new representation of the list. The way 
interpolation is implemented (dynamically) we have to do the 
interpolation every time the list is fetched - values could have changed 
since the last time the list was fetched. That makes returning copies 
when interpolation happens inevitable.

One option I considered was keeping an 'underlying' list of the real 
values and always do interpolation into the same list (allowing us to 
not have to return copies). Unfortunately lists are mutable, so the 
programmer could keep a reference to the list and change it at any 
point, without ConfigObj being able to detect it. I can't think of any 
way of keeping the underlying list in sync with the 'real' list of 
values - unless we use a custom list subclass and tie the lists 
together. I would certainly be open to a patch that provided that... :-)

>> 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.

It isn't a problem if you are only *consuming* the lists - or completely 
replacing the list. It is only for mutation that it is a problem. 
Switching off interpolation for lists only makes interpolation 'safe', 
whilst losing the convenience of list interpolation. As I mentioned in 
the last email, this is one possible approach.

In 4.8 there will be a method for fetching items bypassing 
interpolation. In fact you can already do this with:

     dict.__getitem__(configobj, key)

The list returned by this approach can be safely mutated.

Perhaps this is sufficient?

Michael

>> 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.
>
>    
>
>
> ------------------------------------------------------------------------------
> 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.

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.

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

[David H. <neg...@gm...>]

On Tue, Mar 2, 2010 at 10:23, Michael Foord <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?


As always - thanks for your hard work!


regards,

-David

Re: [Configobj-develop] ANN: 4.7.2 is released

[EntityReborn <ent...@gm...>]

Ah, My bad, misread the note. Sorry.

Re: [Configobj-develop] ANN: 4.7.2 is released

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

On 04/03/2010 02:57, EntityReborn wrote:
> Eh, so... this /doesn't/ fix the mutation problem? (Haven't had time to
> check 4.7.2 :( )
>
>    

I hope it fixes it - it is in the release notes and there is a test for 
it! Please try it out.

The one caveat is that if you are doing string interpolation into list 
values then you will get a copy of the list. If there is no 
interpolation done then you get the original list back.

All the best,

Michael

> ------------------------------------------------------------------------------
> Download Intel® 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.

Re: [Configobj-develop] ANN: 4.7.2 is released

[EntityReborn <ent...@gm...>]

Eh, so... this /doesn't/ fix the mutation problem? (Haven't had time to 
check 4.7.2 :( )

[Configobj-develop] ANN: ConfigObj 4.7.2 Release

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

A new version of ConfigObj has just been released: 4.7.2

This is a bugfix release with several important bugfixes. It is 
recommended that all users of ConfigObj 4.7 update.

* Download: http://www.voidspace.org.uk/downloads/configobj-4.7.2.zip
* PyPI Page: http://pypi.python.org/pypi/configobj
* Documentation: http://www.voidspace.org.uk/python/configobj.html

The new version can be installed with::

     pip install -U configobj

Changelog
========

* BUGFIX: Restore Python 2.3 compatibility
* 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.)
* BUGFIX: ``pop`` now does interpolation in list values as well.
* BUGFIX: where interpolation matches a section name rather than a value
    it is ignored instead of raising an exception on fetching the item.
* BUGFIX: values that use interpolation to reference members that don't
    exist can now be repr'd.
* BUGFIX: Fix to avoid writing '\r\r\n' on Windows when `write` is given
    a file opened in text mode ('w').

See below for important details on the change to using list values with 
string interpolation.

What is ConfigObj?
==============

**ConfigObj** is a simple but powerful config file reader and writer: an 
*ini
file round tripper*. Its main feature is that it is very easy to use, with a
straightforward programmer's interface and a simple syntax for config files.
ConfigObj has a host of powerful features:

* Nested sections (subsections), to any level
* List values
* Multiple line values
* Full Unicode support
* String interpolation (substitution)
* Integrated with a powerful validation system

     - including automatic type checking/conversion
     - and allowing default values
     - repeated sections

* All comments in the file are preserved
* The order of keys/sections is preserved
* Powerful ``unrepr`` mode for storing/retrieving Python data-types

String Interpolation and List Values
=========================

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.



-- 
http://www.ironpythoninaction.com/

[Configobj-develop] ANN: 4.7.2 is released

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

4.7.2 is now out and can be found in the usual place. I'll do some more 
announcements tomorrow. If you are using 4.7.0 or 4.7.1 it is *highly* 
recommended that you update.

A note on the problem with lists and interpolation:

     
http://www.voidspace.org.uk/python/configobj.html#string-interpolation-and-list-values

Michael

On 27/02/2010 21:48, Michael Foord wrote:
> Hello all,
>
> ConfigObj 4.7.2 is in subversion and ready to release. I would
> appreciate it if any of you could test it and check there are no obvious
> issues before I do a release tomorrow.
>
> http://code.google.com/p/configobj/source/browse/trunk/configobj.py
>
> It fixes a number of bugs:
>
> * BUGFIX: Restore Python 2.3 compatibility
> * 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.
> * BUGFIX: ``pop`` now does interpolation in list values as well.
> * BUGFIX: where interpolation matches a section name rather than a value
> it is
> ignored instead of raising an exception on fetching the item.
> * BUGFIX: values that use interpolation to reference members that don't
> exist can
> now be repr'd.
> * BUGFIX: Fix to avoid writing '\r\r\n' on Windows when `write` is given
> a file opened in
> text mode ('w').
>
> The most important fix is that list values are no longer returned as
> copies, except where interpolation changes a value in the list. This
> means that fetching list values is slightly slower than before as it has
> to check afterwards if interpolation has changed any of the members.
> Switching interpolation off if you are not using it fixes this. If this
> causes difficulties then perhaps interpolation into list values should
> be separately configurable, although that would add yet another option
> to the not inconsiderable constructor arguments that ConfigObj has already.
>
> There are a number of outstanding issues most of which are feature
> requests and will have to wait for a 4.8.0 release:
>
> http://code.google.com/p/configobj/issues/list
>
> All the best,
>
> Michael Foord
>
>    


-- 
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.

Re: [Configobj-develop] 4.7.2 in svn

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

On 01/03/2010 18:32, Jason Baker wrote:
>
>     ConfigObj 4.7.2 is in subversion and ready to release. I would
>     appreciate it if any of you could test it and check there are no
>     obvious
>     issues before I do a release tomorrow.
>
>
> A precursory run of envbuilder indicates that there are no obvious 
> errors.  It will be some time before I can say more than that though.  :-)

Cool - thanks. Much appreciated.

Michael

>
> ------------------------------------------------------------------------------
> Download Intel® 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.

Re: [Configobj-develop] 4.7.2 in svn

[Jason B. <jb...@ze...>]

>
> ConfigObj 4.7.2 is in subversion and ready to release. I would
> appreciate it if any of you could test it and check there are no obvious
> issues before I do a release tomorrow.
>

A precursory run of envbuilder indicates that there are no obvious errors.
It will be some time before I can say more than that though.  :-)

[Configobj-develop] 4.7.2 in svn

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

Hello all,

ConfigObj 4.7.2 is in subversion and ready to release. I would 
appreciate it if any of you could test it and check there are no obvious 
issues before I do a release tomorrow.

http://code.google.com/p/configobj/source/browse/trunk/configobj.py

It fixes a number of bugs:

* BUGFIX: Restore Python 2.3 compatibility
* 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.
* BUGFIX: ``pop`` now does interpolation in list values as well.
* BUGFIX: where interpolation matches a section name rather than a value 
it is
ignored instead of raising an exception on fetching the item.
* BUGFIX: values that use interpolation to reference members that don't 
exist can
now be repr'd.
* BUGFIX: Fix to avoid writing '\r\r\n' on Windows when `write` is given 
a file opened in
text mode ('w').

The most important fix is that list values are no longer returned as 
copies, except where interpolation changes a value in the list. This 
means that fetching list values is slightly slower than before as it has 
to check afterwards if interpolation has changed any of the members. 
Switching interpolation off if you are not using it fixes this. If this 
causes difficulties then perhaps interpolation into list values should 
be separately configurable, although that would add yet another option 
to the not inconsiderable constructor arguments that ConfigObj has already.

There are a number of outstanding issues most of which are feature 
requests and will have to wait for a 4.8.0 release:

http://code.google.com/p/configobj/issues/list

All the best,

Michael Foord

-- 
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.

Re: [Configobj-develop] Problem with assigning.

[EntityReborn <ent...@gm...>]

Well, if the differences between 4.6 and 4.7, aren't that big, I'll 
stick with 4.6, and nab the new 4.7 when you up it. :P

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:48, Michael Foord wrote:
> On 27/02/2010 17:45, EntityReborn wrote:
>    
>> Nasty. Hopefully it's a quick fix.
>> Keep me informed!
>>
>> Btw, what are the differences in 4.6 and 4.7.x?
>>
>>      
> Found the problem - it is the way that interpolation is now done in
> lists. It builds a new list, so what you get back is a copy of the
> original list. Dammit...
>    
So, a quick fix is to switch off interpolation in your ConfigObj 
instance when you create it:

     c = ConfigObj(interpolation=False)

I'll do a new release to fix this and a couple of other minor issues as 
soon as I can.

Thanks

Michael Foord

> See the changelog for the other changes:
>
> http://www.voidspace.org.uk/python/configobj.html#version-4-7-0
>
> Michael
>
>    
>> ------------------------------------------------------------------------------
>> Download Intel® 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.

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:31, EntityReborn wrote:
> Yes, this was introduced in 4.7, just downloaded 4.6 and it works 
> flawlessly.
> To explain the code, this allows one to get a value by passing a list 
> of strings to get the value in a path.
Dammit, I'll try and see what changed. I still can't tell whether this 
is a bug or correct behavior.

Michael

-- 
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.

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:45, EntityReborn wrote:
> Nasty. Hopefully it's a quick fix.
> Keep me informed!
>
> Btw, what are the differences in 4.6 and 4.7.x?
>    

Found the problem - it is the way that interpolation is now done in 
lists. It builds a new list, so what you get back is a copy of the 
original list. Dammit...

See the changelog for the other changes:

http://www.voidspace.org.uk/python/configobj.html#version-4-7-0

Michael

> ------------------------------------------------------------------------------
> Download Intel® 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.

Re: [Configobj-develop] Problem with assigning.

[EntityReborn <ent...@gm...>]

Nasty. Hopefully it's a quick fix.
Keep me informed!

Btw, what are the differences in 4.6 and 4.7.x?

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:30, Michael Foord wrote:
> On 27/02/2010 17:27, EntityReborn wrote:
>    
>> Interesting, as I have the 4.7.1 version (or so the gzip says.). I'll
>> switch down and see how that runs.
>>
>>      
> Hmmm... if you do get different behavior between 4.6 and 4.7 then that
> is weird and probably a bug. On the other hand the changes between 4.6
> and 4.7 didn't touch any code that should be capable of causing this
> change...
>
>    

Ok, something is very weird in 4.7 - and yes it is a bug. It looks like 
fetching the list value returns a *copy*, so it is impossible to modify 
the original:

 >>> from configobj import ConfigObj
 >>> c = ConfigObj()
 >>> c['a'] = []
 >>> c['a'].append('foo')
 >>> c['a']
[]

Nasty - thanks for pointing this out. I need to fix it. *sigh*

All the best,

Michael

> All the best,
>
> Michael
>
>
>    
>> ------------------------------------------------------------------------------
>> Download Intel® 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.

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:27, EntityReborn wrote:
> Interesting, as I have the 4.7.1 version (or so the gzip says.). I'll
> switch down and see how that runs.
>    

Hmmm... if you do get different behavior between 4.6 and 4.7 then that 
is weird and probably a bug. On the other hand the changes between 4.6 
and 4.7 didn't touch any code that should be capable of causing this 
change...

All the best,

Michael


> ------------------------------------------------------------------------------
> Download Intel® 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.

Re: [Configobj-develop] Problem with assigning.

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

On 27/02/2010 17:15, EntityReborn wrote:
> Ok, lil background. I'm a noob. Just been messing with Python since the
> beginning of the year.
> Onto the meat.
> Trying to manipulate a value, and with a regular nested dict/list, it
> works fine. With a ConfigObj, the value remains unchanged.
> Have a look here for the testcase: http://paste.pocoo.org/show/183309/
> As no error is raised, I would think that this is an oversite,
> especially as directly setting it, hardcoded, fails as well.
>    

That's a huuuge example so I can't actually see what the code is 
intended to do or why it fails to behave as you expect. Are you able to 
reduce it to a simpler example?

I wonder if the problem is the way that ConfigObj creates sections. If 
you create a new section from a dictionary, the new section is a 
*different object* to the dictionary you use to create it. This means 
that if you create a new section from a dictionary and then *change* the 
original dictionary, those changes will not show up in the section. The 
dictionary is *copied* to create the new section.

 From looking at your code I also wonder if you are managing to create 
config2['test']['obj1']['1'] (turning obj1 into a section). You are 
expecting obj1 to return a list and then relying on a TypeError in 
_getByPath to coerce '1' into an integer. If this doesn't happen somehow 
then you could end up with a data-structure that is different from what 
you expect. Try putting some prints in to see what config2 actually 
contains at the point where it is misbehaving.

Michael

> ------------------------------------------------------------------------------
> Download Intel® 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.