On Wed, 2007-10-03 at 09:15 +0200, Tim Lauridsen wrote:
> seth vidal wrote:
>
>> On Tue, 2007-10-02 at 18:04 +0200, Tim Lauridsen wrote:
>>
>>
>>> Jesse Keating wrote:
>>>
>>>
>>>> On Tue, 02 Oct 2007 14:47:06 +0200
>>>> Oliver Falk <oliver(a)linux-kernel.at> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> OK, that might be the better fix. But doesn't it make sense
>>>>> ConfigParser also allows int as values? I mean any kind of number
>>>>> (int, float, complex) could be handled as string...
>>>>>
>>>>>
>>>>>
>>>> I know not the history of ConfigParser and why it's only strings. I
>>>> suspect it's because ConfigParser's primary usage is to parse
config
>>>> files, and in a file it may be non-obvious how to mark something as an
>>>> int/float rather than a string. The reason pungi uses ConfigParser is
>>>> that prior to using kickstart files we had our own config files.
I'm
>>>> not entirely happy with ConfigParser, but it'd be something of an
>>>> overhaul to switch to some other config system, and not one I was
>>>> willing to make at this point. Maybe during F9...
>>>>
>>>>
>>>>
>>> You can take a look at the config classes in yum (yum/config.py) it
>>> let you define different kind of options types.
>>>
>>>
>>>
>> I've also made a yum-free config.py that takes all the advantages of the
>> yum config file w/o needing the yum-ness of it.
>>
>> you can find it here:
>>
http://skvidal.fedorapeople.org/config.py
>>
>> we just used in in func and it's rather handy.
>>
>> -sv
>>
>>
>>
>>
> Maybe, it should be out into its own package (python module), so that
> potential users could pull it in (yum, func, yumex, pungi etc).
> and it could be maintained in one place.
>
>
actually I was thinking that maybe we should see about submitting it to
be in python core.
-sv