Issue 23 in iniparse: Key/value separator should be '=' rather than ' = '

0 views
Skip to first unread message

inip...@googlecode.com

unread,
Jun 21, 2010, 9:56:05 PM6/21/10
to iniparse...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

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.

inip...@googlecode.com

unread,
Jun 23, 2010, 11:24:40 AM6/23/10
to iniparse...@googlegroups.com
Updates:
Status: Accepted

Comment #1 on issue 23 by psoberoi: Key/value separator should be '='

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.

inip...@googlecode.com

unread,
Jun 23, 2010, 7:55:57 PM6/23/10
to iniparse...@googlegroups.com

Comment #2 on issue 23 by chris.morganiser: Key/value separator should

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

Reply all
Reply to author
Forward
0 new messages