``ConfigParser.write()`` writes a superfluous final blank line.

Example::

    import configparser
    cp = configparser.ConfigParser()
    cp['section1'] = {'key': 'value'}
    cp['section2'] = {'key': 'value'}
    with open('configparser.ini', 'w') as f:
        cp.write(f)

The output file 'configparser.ini' will be:: (I added line number)

  1 [section1]
  2 key = value
  3 
  4 [section2]
  5 key = value 
  6 

with a superfluous final blank line.


Compare to ``GLib.KeyFile``::

    import gi
    gi.require_version('GLib', '2.0')
    from gi.repository import GLib
    kf = GLib.KeyFile()
    kf.set_string('section1', 'key', 'value')
    kf.set_string('section2', 'key', 'value')
    kf.save_to_file('glib.ini')

The output file 'glib.ini' will be:: (I added line number)

  1 [section1]
  2 key=value
  3 
  4 [section2]
  5 key=value

without a superfluous final blank line.

Its not a superfluous blank line. It is standard convention for Unix tools to end text files (of which ini files are a kind of text file) with a final newline \n. There are various reasons for this, but it doesn't matter what those reasons are, the important thing is that it is (or at least, ought to be) intentional for the ini file to end with a \n.

It is not an error for the file to end with one (or more) blank lines, regardless of the platform; it is more convenient for all lines to a \n delimiter, rather than making the last line special.

I do not believe there is any good reason to complicate the code and the API with an unnecessary "trim_final_blankline" parameter, but even if there is a good reason, the default would have to be False to remain backwards compatible.

Unless you have a good reason why it should be considered an error for the INI file to end in a blank, this patch should be rejected, and instead we should have an explicit test to ensure that the INI file is always written with a final blank.

(Of course, when *reading* INI files, it should accept them either with or without final blank.)

Oh, I forgot... even if it is decided that this trim_final_blankline parameter was desirable, the patch isn't sufficient to be accepted. You would need to also supply documentation and tests.

**It's not final newline \n !**

Maybe what I said confused. The "final blank line"
does not mean the "final newline char".
It means an extra blank line after last line.

It might be clearer to represent it in a string::

    '[section1]\nkey = value\n\n[section2]\nkey = value\n\n'

It has *two* \n at end. I think it should be only one.

Patch updated, included documentation and tests.

Adding two new parameters to control so tiny detail of the output looks excessive to me. What if just change the default behavior and never output a final blank line?

I’m afraid of breaking the backward compatibility.

If we treat the original behavior as a bug,
it’s much easier to write a patch
that just changes the default behavior
and never outputs a final blank line.

I have looked through the testsuite of it.
It seems that the original author had knew
the final blank line and treat it as
expect result. I’m not sure about it.

On Sat, Mar 10, 2018 at 06:37:28AM +0000, TitanSnow wrote:
> 
> TitanSnow <tttnns1024@gmail.com> added the comment:
> 
> If we treat the original behavior as a bug,
> it’s much easier to write a patch
> that just changes the default behavior
> and never outputs a final blank line.

Remind me, why do we care about that extra blank line?

> I have looked through the testsuite of it.
> It seems that the original author had knew
> the final blank line and treat it as
> expect result. I’m not sure about it.

Is there a test for it? If so, then it should stay unless the author 
agrees it can go, or we get approval on the Python-Dev mailing list.

I thought a blank line between sections is just for readability, and no program will break if drop it. Removing the final blank line can harm the readability in the case of sequential writes to the same file (unless we detect the start of the file, that is problematic in the case of non-seekable streams). But I didn't thought that a superfluous final blank line causes any problems. What software has a problem with it?

> But I didn't thought that a superfluous final blank line causes any problems. What software has a problem with it?

Currently I have not found a program that has problem with
the superfluous final blank line, and I think there won’t be.

> Removing the final blank line can harm the readability in the case of sequential writes to the same file

Sorry that I have not thought about this.
In this way, the prev patch that adds two new parameters might be better.

> Remind me, why do we care about that extra blank line?

Well, though it seems that that extra blank line won’t cause any problem,
it does not look nice I think, and is different with INI files written
by other applications.

For the case of sequential writes to the same file,
I think it’s a invalid use case.
The file can be created or modified by
user or other applications, breaking the assume of
ConfigParser. It’s better to have a method to merge
two ConfigParser objects then writes it into the file
at one time.

If there is no real problem, I think it is not worth to change this.