Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
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
(Of course, when *reading* INI files, it should accept them either with or
without final blank.)
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list