|
From: Michael F. <fuz...@vo...> - 2012-08-19 19:16:04
|
On 19 Aug 2012, at 12:37, Patrick Totzke <pat...@gm...> wrote: > Hi! > > I'm not sure if it makes much sense to report this here as the list seems more or less dead.. Pretty much. :-) I'm not using ConfigObj myself these days, so development has stalled. The *best* place to report an issue is on the bug tracker, so that it doesn't get lost: http://code.google.com/p/configobj/issues/list > Anyhow, I ran into something nasty with configobj/validate. I think the subject says it all: > > If your configspec says > > foo = string(default=None) > > and your config reads > > foo = bar, baz > > validation using cfg.validate(Validator()) does not fail and afterwards cfg.foo > foes not contain "bar, baz" but ["bar", "baz"]. > Apparently one can force lists using > > foo = force_list > > in the spec, bot one cannot force *not* list, which from my perspective would be > the logical behaviour of spec "string". So parsing into lists is done by ConfigObj before a value is sent for validating. The "right" thing to do is to escape the comma with quotes: > > and your config reads > foo = "bar, bar" Having said that, if your spec specifies a string then a list should *fail validation*. You could write a custom validator yourself that will force non-list values. All the best, Michael Foord > cheers, > /p > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > 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 |