Menu
▾
▴
Re: [Configobj-develop] List handling in Validator
|
From: Michael F. <fuz...@vo...> - 2011-01-04 15:07:24
|
On 04/01/2011 15:03, David Hostetler wrote: > Stefan, you're conflating the concepts of data format and programming > language syntax (i.e. code). > What you've said is true David. Reading Stefan's mind (because he hasn't explained his use case) I imagine that he has data input from the user (or some other source) that he wants to treat in the same way as if it had been written in a config file. He is annoyed that just setting it on a ConfigObj instance doesn't do that. For all the reasons both you and I have explained it isn't a good idea for it to work that way anyway... However, given that he *may* have a reasonable use case for taking string data and then treating it as unparsed config data, I'd be happy with an API that *allows* him to do that without making it the default behaviour. All the best, Michael Foord > 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... <mailto:neg...@gm...> > > > > On Tue, Jan 4, 2011 at 09:18, Stefan Parviainen <pa...@ik... > <mailto: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... <mailto: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... > <mailto:Con...@li...> > https://lists.sourceforge.net/lists/listinfo/configobj-develop > > > > ------------------------------------------------------------------------------ > 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 -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html |
