Menu
▾
▴
Re: [Configobj-develop] ANN: ConfigObj 4.7.2 Release
|
From: Michael F. <fuz...@vo...> - 2010-03-09 14:42:55
|
On 09/03/2010 14:37, David Hostetler wrote: > 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. I think having a 'locate' method (or similar) that fetches the values without interpolation is the right answer (and has been requested by someone else). That way if you want to mutate a list then you fetch it with locate instead of fetching it directly. At least then there is a straightforward rule for solving the problem without adding any more options or removing the list interpolation feature. All the best, Michael > > cheers, > > -David > > > > On Thu, Mar 4, 2010 at 10:35, Michael Foord <fuz...@vo... > <mailto: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... <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® 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... <mailto: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® 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... <mailto: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® 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... > <mailto:Con...@li...> > https://lists.sourceforge.net/lists/listinfo/configobj-develop > > > > ------------------------------------------------------------------------------ > 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. |
