New issue 23 by chris.morganiser: Key/value separator should be '=' rather
than ' = '
http://code.google.com/p/iniparse/issues/detail?id=23
What steps will reproduce the problem?
1. Create a key in the normal way
What is the expected output? What do you see instead?
As this is an INI parser (not a config parser) I expect it to do more or
less what Windows' kernel32::WritePrivateProfileString writes:
Key=value
However, due to ini.py, line 108 - OptionLine.__init__, parameter four,
separator=' = ', it writes it with spaces around the equals sign:
Key = value
When wanting to edit correctly formatted INI files, this is a problem. If
editing existing values the lack of whitespace will be preserved, but if
new values are created they don't match.
What version of the product are you using? On what operating system?
0.4, Python 2.6
Please provide any additional information below.
Another solution would be to handle this sort of thing with some **config
on the INIConfig or something like that. That'd require a fair bit of work
to do well, though. And I still think that the default should be '=' rather
than ' = '.
I'd prefer this to be fixed in iniparse itself so that it behaves like a
proper INI parser, but if you don't want to do this I can maintain a
version of my own for my project... with those two characters removed.
Comment #1 on issue 23 by psoberoi: Key/value separator should be '='
rather than ' = '
http://code.google.com/p/iniparse/issues/detail?id=23
Hmm, I wasn't aware of kernel32::WritePrivateProfileString. I agree that
it would be nice to be able to control the generated output to make it fit
the desired conventions.
A few other issues have come up in the past regarding other INI dialects
that differ from ConfigParser in small ways. There was the include syntax
that mercurial uses, and I remember someone complaining that iniparse did
not allow leading whitespace on lines.
To handle all these variations, I'm thinking of introducing an INIDialect
class. There will be a default dialect, and you'll also be able to pass in
a dialect to the constructor. Some common dialects could be pre-defined.
Dialects could affect the syntax in small ways, and control output
formatting like which separator to use and whether to put spaces around it.
That sounds like a very good solution to it. I've listed a few other
inconsistencies in issue 24 (to not pollute this one, I should have just
made this one more general to start with). Those are also things for which
an INIDialect would fit the bill very nicely.
With your INIDialect class, you could have it auto-select a dialect to a
certain extent if it is given an open() argument -
fp.name.lower().endswith('.ini')