Re: [Configobj-develop] new to configobj - questions

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

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
>