Menu
▾
▴
Re: [Configobj-develop] new to configobj - questions
|
From: Jeremy G. <jr...@gm...> - 2009-10-18 13:44:42
|
David, thanks for taking the time to carefully explain this, it helps a lot. I was confused about what validation is intended to do. I was thinking that validation should just fail if there's not an explicit section label in the config file (e.g., Michael's example). > there is nothing semantically wrong with the cfg content that you provided > for validation. I was thinking that there was something wrong--namely no section '[b]'. But it seems that a valid section can be given either a) explicitly (in the config file), or b) implicitly (in the spec file -- but only if there are defaults for the items in the section). I was only expecting "explicitly present" to count as valid, not the implicit part. So as I now understand it, validation is not merely a process to *check* whether the contents of a config file are valid by themselves (explicit), but also a process to try to *make* those contents valid, reconstructing anything necessary (such as missing sections, i.e., making the implicit part explicit again). and it can only do such reconstruction if there are default values. thanks again, --Jeremy On Sat, Oct 17, 2009 at 9:00 PM, David Hostetler <neg...@gm...> wrote: > I have to respectfully disagree with your description of a 'nicer' behavior. > > What you're proposing would break the clean semantic behavior of cfg parsing > and validating. > > If a user deletes a section name, but leaves the key/value pairs that > previously belonged to it, then those key/value pairs *ARE* part of the > preceeding section! What you're asking is for validate to complain about a > scenario that is only a problem in your contorted use case. It is > simultaneously a perfectly valid scenario in other cases. And furthermore, > there is nothing semantically wrong with the cfg content that you provided > for validation. > > The format and interpretation of cfg content is unambiguous and semantically > robust. It's behavior in the scenario you've described is both predictable > and exactly what I would want it to do. If you change a cfg file in the way > you describe, and validate it with the same validation spec, it's adhering > to both the cfg rules and the validation spec perfectly. You omitted a > section whose values all have defaults, so it provides those defaults for > you. You have key/value pairs in another section that are prefectly > legitimate key/value pairs, and if there were validation rules that applied > to those keywords in that particular section, they would get applied > normally. Just because you didn't want those key/value pairs in that > section -- i.e. their presence there is inadvertent and a result of someone > changing cfg content in an unintended/undesirable way -- doesn't mean that > it is the responsibility of configobj or validate to either fix or detect > it, because the changes themselves are perfectly valid, and the modules > can't determine intent. > > What you're asking is like asking the python interpreter to complain about a > comment in the code because maybe someone inadvertently put a '#' in front > of some lines. How is the interpreter supposed to know the difference > between an intended comment and an unintended comment? > > > regards, > > David Hostetler > > > > On Sat, Oct 17, 2009 at 14:41, Jeremy Gray <jr...@gm...> wrote: >> >> at risk of getting academic about this (sorry, that's my day job, >> being an academic :-) ), I have one more thought.... >> >> and I want to emphasize that I'm certainly not asking for a new >> feature, or somehow insisting that there's a bug. not at all! its your >> program, it works, and I'm glad to be using it. >> >> >> then there is at least the >> >> possibility that they have been changed right under the user's nose. >> >> >> > >> > Only if they didn't supply them (i.e. nothing has 'changed'). >> >> this may be true most of the time. in my case, however, I allow users >> to edit the config files (which I recognize is probably a bad idea, >> and I plan to rewrite so they can't do this). currently, my users can >> set specific values to something other than the defaults. if the user >> then deletes only the section name, all values within that section >> revert to defaults when validate is called -- so something has indeed >> changed. (the previously-edited values are retained but now they are >> in a different section, and so no longer accessible reliably.) and >> there's not a handy flag that I can catch to handle this situation. I >> could track which items were non-default, and then after validating >> check if some of the values had become the default (by comparing each >> against using config.defaults). but it would seem more straightforward >> to have validation fail and report a missing section, which could then >> be reset to defaults if so desired. (in my case I would not do that -- >> its not always a desirable action). >> >> anyway, just my .02 -- its a very nice set of tools. >> >> > You can always use 'config.defaults' for a list of all entries filled >> > from default values. >> >> interesting... >> >> looking forward to 4.7, >> >> --Jeremy >> >> >> > All the best, >> > >> > Michael Foord >> >> eventually I'll be structuring things so that my users cannot edit the >> >> config file directly, avoiding this situation. >> >> >> >> >> >>> In order to fill in the default >> >>> ConfigObj *has* to create the section so it is no longer missing. >> >>> >> >> >> >> that makes sense. >> >> >> >> thanks again, >> >> >> >> --Jeremy >> >> >> >> >> >> >> >>> It would also make things harder for error handling code - if you have >> >>> to handle a missing section then you would no longer know if the >> >>> section >> >>> is actually present in the resulting ConfigObj instance or not... >> >>> >> >>> All the best, >> >>> >> >>> Michael Foord >> >>> >> >>>> --Jeremy >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------------ >> >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> >>>> is the only developer event you need to attend this year. Jumpstart >> >>>> your >> >>>> developing skills, take BlackBerry mobile applications to market and >> >>>> stay >> >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> >>>> http://p.sf.net/sfu/devconference >> >>>> _______________________________________________ >> >>>> Configobj-develop mailing list >> >>>> Con...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/configobj-develop >> >>>> >> >>>> >> >>> -- >> >>> http://www.ironpythoninaction.com/ >> >>> http://www.voidspace.org.uk/blog >> >>> >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> >>> is the only developer event you need to attend this year. Jumpstart >> >>> your >> >>> developing skills, take BlackBerry mobile applications to market and >> >>> stay >> >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> >>> http://p.sf.net/sfu/devconference >> >>> _______________________________________________ >> >>> Configobj-develop mailing list >> >>> Con...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/configobj-develop >> >>> >> >>> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> >> is the only developer event you need to attend this year. Jumpstart >> >> your >> >> developing skills, take BlackBerry mobile applications to market and >> >> stay >> >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> >> http://p.sf.net/sfu/devconference >> >> _______________________________________________ >> >> Configobj-develop mailing list >> >> Con...@li... >> >> https://lists.sourceforge.net/lists/listinfo/configobj-develop >> >> >> > >> > >> > -- >> > http://www.ironpythoninaction.com/ >> > http://www.voidspace.org.uk/blog >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> > is the only developer event you need to attend this year. Jumpstart your >> > developing skills, take BlackBerry mobile applications to market and >> > stay >> > ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> > http://p.sf.net/sfu/devconference >> > _______________________________________________ >> > Configobj-develop mailing list >> > Con...@li... >> > https://lists.sourceforge.net/lists/listinfo/configobj-develop >> > >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Configobj-develop mailing list >> Con...@li... >> https://lists.sourceforge.net/lists/listinfo/configobj-develop > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop > > |
