|
From: Thomas Sturges-A. <zi...@ho...> - 2011-10-28 17:04:52
|
Thanks for all your input. I did quite quickly notice the limitations of the code but I think I have managed to work round it for my purposes. I am building a adventure game engine for fun/honing my Python knowledge and so I wanted to be able to check if, for example a given choice had requirements or effects (which would be stored in a sub-section) so that code relating to processing these could be bypassed. As such I am mostly going to be checking for a subsection in a section that is already known to be there (so no chance of a KeyError). The code I will probably use is 'Basics' in character.sections #for checking for primary sections 'name' in character['Basics'].scalars #for checking for options in a (known) primary section 'stuff' in character['Basics'].sections #for checking for sub-sections in a (known) primary section 'blah' in character['Basics']['stuff'].scalars #for checking for options in a (known) sub-section in a (known) primary section etc if need be.... I won't be using this for a bit though as I have only got just (today) finished off the adventure and character loading system but I didn't want to start building configobj into the code if then it would screw me over down the line. The methods above are simple enough so it looks like everything should be cool :) . Is somewhat of a shame they can't be used in a class thougth (as single quotes are needed inside and out of the class which I don't think is possible) because it would have been a great entry for me into classes (believe it or not I haven't used them yet). The GitHun Gist (I haven't got my head round Git yet) can be found here: https://gist.github.com/1322726 if you're interested. Thanks again! For a great module and help using it! Thomas Sturges-Allard From: neg...@gm... Date: Fri, 28 Oct 2011 10:44:32 -0400 Subject: Re: [Configobj-develop] has_section function? To: fuz...@vo... CC: con...@li...; zi...@ho... On Fri, Oct 28, 2011 at 10:18, Michael Foord <fuz...@vo...> wrote: On 28/10/2011 15:08, David Hostetler wrote: Hey Michael, Unless I'm mistaken, your suggestions don't completely address Thomas' question. configfile.sections and configfile.scalars don't expose nested entries. So yes, he can use those, but they'll be misleading unless he's using configuration data that he can guarantee isn't nested, in which case he's not any better off than when he was using ConfigParser. Well he is because you can't have nested sections *at all* with ConfigParser (and there are lots of other reasons to prefer ConfigObj...). Of course - lots of really good reasons to prefer ConfigObj. :) I certainly didn't mean for that to sound disparaging. Just that if he migrated to ConfigObj because he wanted nested data, then artificially constraining himself to not be nested defeats the purpose. I *think* that he was hoping there was some super-convenient way to ask a ConfigObj instance to be deeply introspective and test for a given section-name/key-name anywhere in the cfg hierarchy. Not terribly difficult to do with a smidge of recursion, but not natively offered by the ConfigObj interface as far as I know. The code I suggested was an exact equivalent of "has_section" and "has_option" in ConfigParser - but you're right, this code only checks the current section and doesn't recurse. You could write a recursive version easily, but what would that be useful for? Knowing that *somewhere* inside a nested data structure the section/option exists isn't useful, because you still have to write the recursive code to find it. By the time you've done that you've written the code to check as well... All true. If I were to write something addressing this concept, I'd have it actually return the entity that it was testing for. I.e. if it returns None, the desired item doesn't exist, otherwise it does and here it is for your convenience. configob (and validate) rock, as always. :) regards, -hoss David Hostetler neg...@gm... |