Re: [Configobj-develop] List handling in Validator

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

Stefan, you're conflating the concepts of data format and programming
language syntax (i.e. code).

The entire purpose of ConfigObj, and it's config file format, rules, and
API, is to allow data to successfully and robustly make the transition
_between_ a text-based file/storage format and program code.

The purpose is NOT to muddy the distinction between data saved in a storage
format and the specification for literals in the Python data model.

My point is that I can do foo = 1,2  in a config file and it works

correctly, but if I do config["foo"] = '1,2' it does not work.


config["foo"] = '1,2'  is Python code!!   It works, and does precisely what
it should.  The specification for Python's lexical data model is
long-standing, proven, consistent, understood, and powerful.   And you're
proposing that ConfigObj should intentionally subvert it for convenience!?

A programmer should _never_ have to ask themselves, when typing out an
assignment in code, "oops... am I writing Python, or am I writing
ConfigObj?"   But that's exactly the kind of ambiguity your proposal would
be injecting.

One of the most useful concepts a programmer can embrace is that of
establishing and respecting a very firm and distinct boundary between stored
data and programmatic data.  This is one of the 'tricks' of successful
i18n/L10n programming, but it's equally effective as a general rule.

With respect to ConfigObj use, applying that concept means respecting the
boundary between the config storage syntax and the ConfigObj API in Python
space.  Once a blob of stored config text has been digested and converted
into programmatic/Python variables, you're squarely in Python land.  Write
Python.  You should neither want nor expect any of the various and sundry
details of the storage format itself to intrude upon your ability to
exercise and rely upon the Python data model.

In other words, once data has been processed and is in a ConfigObj instance,
a list is only ever list because it's a list.  type(x) == types.ListType.
To violate that is to invite madness and anarchy.  And note that the true
Python connoisseur wouldn't be doing explicit type checking anyway, they'd
be duck-hunting.  :)


cheers,

-hoss

David Hostetler
neg...@gm...



On Tue, Jan 4, 2011 at 09:18, Stefan Parviainen <pa...@ik...> wrote:

> I see what the source of confusion might be. I am talking about values
> after validation has been performed. So when I say that I assign
> something and then the value is of type something I mean that it is
> after validation. Maybe this clears up some issues?
>
> On Mon, Jan 3, 2011 at 4:49 PM, Michael Foord <fuz...@vo...>
> wrote:
> >> So when parsing the config file "1,2" is indeed interpreted as a list,
> > No. 1,2 without quotes is a list. '1,2" with quotes is a string that
> happens
> > to contain a comma.
> My point is that I can do foo = 1,2  in a config file and it works
> correctly, but if I do config["foo"] = '1,2' it does not work. I would
> fully understand that "foo = '1,2'" and config["foo"] = "'1,2'" would
> not work (Notice the quotes inside the quotes). I think it's confusing
> that I can write one thing in a file, but not the exact same thing in
> the source. In this case I assign 1,2 (n.b. without any quotes) in
> both cases.
>
> > Otherwise, as I indicated, string values that contain commas can be
> incorrectly split into lists.
> Can you name a situation when splitting a string when something
> expects a list would lead to unwanted results? Not splitting the
> string, and instead assigning it directly _always_ leads to incorrect
> results when a list is expected.
>
> > However quoted strings can contain commas that don't represent lists
> > which is why your suggestion of always splitting on commas is bad.
> I'm certainly not suggesting that a string containing commas is
> _always_ interpreted as a list. Only when a list is expected!
> Maybe there is an error in my code, and it is always split, but that
> is certainly not the intention.
>
> > What would be the use case of force_int? I don't really understand your
> > point here.
> Assigning a string to something expecting an integer "just works".
> Assigning a string to something expecting a list does not, instead
> force_list is needed. Don't you see the inconsistent behavior? I don't
> see why integers can be converted automatically (when needed) but
> lists require a separate type for this to work.
>
> >  If you want a list value then assign a list.
> I could similarly say that if you want an int value then assign an
> int. Yet integer conversion from a string happens automatically. Why
> does not list conversion happen?
>
> > Alternatively, it sounds like a reasonable feature request to ask for a
> > method to parse a string using the ConfigObj syntax rules - so that you
> can
> > use ConfigObj syntax for assigning strings.
> I think that an assignment should work the same, regardless if it's in
> a config file or in the source code.
>
> Once again:
> Assume the spec:
> p = list()
>
> Case 1, Conf file:
> p = 1,2
>
> Case 2, in source:
> config['p'] = '1,2'
>
> In both cases the right-hand side is: 1,2. The quotation marks in case
> 2 is there because of Python syntax. I am still assigning the value
> 1,2 without any quotes, just like in case 1.
>
> Given the above spec, in both cases, after validation, I expect p to
> be the list ['1','2']. Currently case 1 gives ['1','2'] while case 2
> gives a validation error. I don't think it makes sense to get
> different results given that the right-hand side is the same in both
> cases.
>
> --
> Stefan Parviainen
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment,
> and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>