INITools is a variety of modules for manipulating .ini-style
files. This is similar to ConfigParser, only
easier to build on than that library.
I’m not (very) actively developing this library, though I do use it
from time to time. Anyone interested in doing something with it
should feel free to take it in whatever direction they find
interesting. You can contact me at ianb@colorstudy.com
A whirlwind tour of the modules:
- iniparser:
- The most basic module, this is a simple parser for .ini-style
files. You subclass the parser and build your objects as the file
is parsed. See initools.iniparser.BasicParser for a minimal
example.
- configparser:
- A module compatible with the standard library
ConfigParser module – it doesn’t actually share any code with
that module, but supports all the same thing plus some other
(optional but disabled) features.
- configwrapper:
- This offers a simple Config object that takes a single
filename as an argument, and provides a simple interface to that
file. The closest thing here to ConfigParser, I guess.
- lazyiniparser:
- An ini parser that keeps complete track of the files it draws
from, including order, filename/line number, and comments. It can
be used for systems that support round-tripping (reading and
writing files).
- inischema:
- A thought experiment, mostly. Supports a class-based schema
definition, and reads files matching them against the definition.
Not terribly advanced. It would be more interesting if it used
FormEncode for schemas, or maybe
something based on (or similar to) optparse. A
config-file compliment to optparse would be generally useful,
but probably would be based more on iniparser or
lazyiniparser.
- nested:
- A nested dictionary-like object. Lets you fold several
dictionaries into a single view, including nested dictionaries.
- lazyloader:
The fanciest and most complicated of the modules. This is where
it seemed to get out of control (especially combined as it is with
nested). This supports loading several files, doing
conversion with source tracking, parsing the keys and sections to
create highly nested structures, and folding a configuration back
onto itself (for context-sensitive configuration).
This is complex enough that it becomes necessary to debug your
configuration files, which sucks.
I don’t have any particular plans, but if you do that’s cool. The
optparse thing would be cool.
- Fix to allow subclasses to implement error_missing_equal to not throw
an error (i.e. ignore this error)
- The .write() method (which writes out an edited config file) was
not giving
- Added ignore_missing_files configuration value on ConfigParser;
if False (default True) then conf.read([filename]) will raise an
exception if the filename doesn’t exist.
- Added an _open method on ConfigParser that can be overridden to,
for example, support HTTP urls.
- Added initools.configparser.ConfigParser.write_sources(fileobj,
sources), which writes all the settings in one of the sources in
the set sources. Also
initools.ConfigParser.CanonicalFilenameSet which is a set-like
object that accepts relative and absolute (or case-different files
on Windows) as the same.
- Added method initools.configparser.ConfigParser.setting_location(section, option)
which returns the (filename, line_number) of the setting (or None, None).
- Fixed a problem when writing files using inline comments, with
initools.configparser.ConfigParser – after parsing the wrong
value would be put in as a comment, creating an invalid configuration file.