Re: [Configobj-develop] ConfigObj Changes

[Nicola L. <ni...@te...>]

> I *won't* implement get because it clashes with a dictionary method. If
> I implement the ``ConfigParser`` compatibility layer then that will
> change (but be on a subclass).

OK.


> My intention is to make these methods *section* methods, so they are
> available on all subsections, and to keep the ConfigParser method
> signature. For values *not* in a subsection, this leads to the slightly
> awkward syntax :
> 
> cfg = ConfigObj(cfg_file)
> val = cfg.getboolean(None, 'key')

There's no explicit outer section, so None is an appropriate value, if a
bit quirky.


> The alternatives are :
> 
> * To reverse the order of the arguments, with section defaulting to
> None. This leads to confusion in the (theoretical) ConfigParser
> compatibility layer, which will of course  be reversed back. It is
> *slightly* more friendly for normal use though.

I don't like it, equivalent APIs should be consistent, otherwise it's like
setting up traps for the unwary user,


> * To make it a method on ConfigObj (*not* sections) and allow section to
> be a string *or* a reference to a subsection - in which case the
> specified key would be taken from that.

How would you specify nested sections in a string? Dotted notation? Section
names are not restricted to Python identifier syntax, right? Anyway, having
methods on section objects seems more versatile.


> Should I then remove ``istrue`` (added in 4.1.0) which is effectively
> the same as ``getboolean`` ? I would deprecate it and add a warning
> until 4.3.0.

Yes, better avoid multiple ways of doing the same thing, especially if it's
a recent thing.


> The unicode changes are reasonably straightforward. I'll re-implement
> the system used in ConfigObj 3. (Unless anyone raises any objections or
> suggests an alternative).
> 
>  You will be able to pass in an (optional)  'encoding' keyword. If
> present, this will be used to decode the input. This maps to an
> 'encoding' attribute which will be used used to encode when writing (and
> can obviously be changed).
> 
> There will also be a 'default_encoding' keyword/attribute to override
> the system default encoding. This is used (to decode) any values that
> are byte-strings. These need to be turned into unicode prior to writing
> out in the specified output encoding.
> 
> If encoding is None (the default) then no encoding or decoding is
> explicitly done. This means the default behaviour for ConfigObj is
> completely unchanged.

Sounds reasonable.

-- 
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