[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib ConfigParser.py,1.16,1.17

[Guido van Rossum]

[Fred]
>   I agree that the API to ConfigParser sucks, and I think also that
> the use of it as a general solution is a big mistake.  It's a messy
> bit of code that doesn't need to be, supports a really nasty mix of
> syntaxes, and can easily bite users who think they're getting
> something .ini-like (the magic names and interpolation is a bad
> idea!).  While it suited the original application well enough,
> something with .ini syntax and interpolation from a subclass would
> have been *much* better.
>   I think we should create a new module, inilib, that implements
> exactly .ini syntax in a base class that can be intelligently
> extended.  ConfigParser should be deprecated.

Amen.

Some thoughts:

- You could put it all in ConfigParser.py but with new classnames.
(Not sure though, since the ConfigParser class, which is really a
kind of weird variant, will be assumed to be the main class because
its name is that of the module.)

- Variants on the syntax could be given through some kind of option
system rather than through subclassing -- they should be combinable
independently.  Som possible options (maybe I'm going overboard here)
could be:

	- comment characters: ('#', ';', both, others?)
	- comments after variables allowed? on sections?
	- variable characters: (':', '=', both, others?)
	- quoting of values with "..." allowed?
	- backslashes in "..." allowed?
	- does backslash-newline mean a continuation?
	- case sensitivity for section names (default on)
	- case sensitivity for option names (default off)
	- variables allowed before first section name?
	- first section name?  (default "main")
	- character set allowed in section names
	- character set allowed in variable names
	- %(...) substitution?

(Well maybe the whole substitution thing should really be done through
a subclass -- it's too weird for normal use.)

--Guido van Rossum (home page: http://www.python.org/~guido/)