|
From: Nicola L. <ni...@te...> - 2006-01-30 20:57:22
|
>> I am going to implement these as section methods. My initial idea was >> to implement them using the ConfigParser names and syntax. This means >> you would have to specify a subsection, but could specify None to get >> values in the section you are calling from. >> >> In order to avoid this there are three (reasonable) options : >> >> 1) Implement ``asbool`` *and* ``getbool`` methods - ``getbool`` >> following ConfigParser signature. >> 2) Just implement ``asbool`` and leave ``getbool`` for a ConfigParser >> compatibility layer - if it ever happens. >> 3) Implement ``getbool`` but make the second argument optional (by >> having None as the default). If no second argument is specified, treat >> the first argument as a key *not* a section... >> >> I have a mild preference for 2) but quite like 3). 3) is weird because >> it changes the meaning of the first argument *if* you provide a second... >> >> Opinions please... > Actually I like 3. It keeps compatibility with ConfigParser (benefit of > familiarity), and achieves both aims. > > If you supply one argument it's a key, if you supply two they are > ``section, key``. > > Oh, except it's ``getboolean`` not ``getbool``. :-) I think I'll disagree here. I concur that having to specify None for no subsection is a bit inconvenient. However, breaking the rule that optional parameters should be last in the signature is worse, IMO. I seem to recall a couple such cases in the standard library, and they feel out of place and inconsistent with the rest. Moreover, with option 3) you're not really compatible with ConfigParser anymore, since you changed the signature, by allowing one to use just one param. That may cause surprises in case of mistakes. Maybe it would be better to have separate methods with just one param, and that would be option 1), if I'm not mistaken. -- Nicola Larosa - http://www.tekNico.net/ People just don't want to be pestered - they want shit to happen without being bugged. If technology is to help, it must be seren- dipitous rather than strident. -- Nathan Torkington, November 2005 |