Menu
▾
▴
Re: [Configobj-develop] ANN: ConfigObj 4.7.2 Release
|
From: David H. <neg...@gm...> - 2010-03-09 14:38:08
|
Hey Michael, Sorry to delay in replying. I don't have any great proposal either. I appreciate the dilemma. I'll probably mull this over some more in the background and if I come up with anything clever I'll certainly lob it up here for review before bothering with patchwork. cheers, -David On Thu, Mar 4, 2010 at 10:35, Michael Foord <fuz...@vo...>wrote: > 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...>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® 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 lis...@li...://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® 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 lis...@li...://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® 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 > > |
