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