Key/value separator should be '=' rather than ' = '

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by chris.morganiser on 22 Jun 2010 at 1:55

[GoogleCodeExporter]

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.

Original comment by psobe...@gmail.com on 23 Jun 2010 at 3:24

• Changed state: Accepted

[GoogleCodeExporter]

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

Original comment by chris.morganiser on 23 Jun 2010 at 11:54