Menu
▾
▴
configobj-develop
|
From: Michael F. <fuz...@vo...> - 2010-03-02 15:51:45
|
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/ |
|
From: David H. <neg...@gm...> - 2010-03-04 15:18:11
|
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 |
|
From: Michael F. <fuz...@vo...> - 2010-03-04 15:25:24
|
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® 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. |
|
From: Jason B. <jb...@ze...> - 2010-03-04 15:45:27
|
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. |
|
From: Michael F. <fuz...@vo...> - 2010-03-04 15:49:25
|
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® 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. |
|
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 > > |
|
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. |
|
From: Michael F. <fuz...@vo...> - 2010-03-04 15:35:19
|
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... >> 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... > 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. |
Thanks for helping keep SourceForge clean.
X