Am Di., 13. Juli 2021 um 15:02 Uhr schrieb <sandhoners123@gmail.com>:

Right now, writelines is a very big misnomer to many python developers, especially beginners who would expect writelines to put new lines at the end of every element in the list

My suggestion is to have either a writelines2 or a newline kwarg which does put new lines automatically at the end of every line written

I like the idea of having a kwarg for writelines <https://docs.python.org/3/library/io.html#io.IOBase.writelines>. Do you want a boolean like "append_newlines=True" or a string like "append_string='\n'" Regards, Thomas

Maybe (to be consistent with other functions like print), end= since that would allow even custom line endings

It would produce a\nb\nc\n. Essentially it would put \n after every value gotten from a iterator

On Tue, 13 Jul 2021 at 15:56, Jonathan Fine <jfine2358@gmail.com> wrote:

The interactive help message for writelines gives no help. I've made an enhancement request to b.p.o.

help(open('/dev/zero').writelines) gives no help https://bugs.python.org/issue44623

Please take a look.

Works for me on Python 3.9:

...

...

help(open("nul").writelines) Help on built-in function writelines:

writelines(lines, /) method of _io.TextIOWrapper instance Write a list of lines to stream. Line separators are not added, so it is usual for each of the lines provided to have a line separator at the end.

On 2021-07-13 at 14:11:15 -0000, sandhoners123@gmail.com wrote:

Maybe (to be consistent with other functions like print), end= since that would allow even custom line endings

As it stands, writelines is consistent with readlines. Both preserve newlines. All else being equal, the following copies a file: input_file = open(input_pathname, 'r') output_file = open(output_pathname, 'w') lines = input_file.readlines() output_file.writelines(lines) input_file.close() output_file.close()

On 2021-07-13 15:18, Eric V. Smith wrote:

On 7/13/2021 9:52 AM, Thomas Güttler wrote:

...

Am Di., 13. Juli 2021 um 15:02 Uhr schrieb <sandhoners123@gmail.com <mailto:sandhoners123@gmail.com>>:

Right now, writelines is a very big misnomer to many python developers, especially beginners who would expect writelines to put new lines at the end of every element in the list

My suggestion is to have either a writelines2 or a newline kwarg which does put new lines automatically at the end of every line written

I like the idea of having a kwarg for writelines <https://docs.python.org/3/library/io.html#io.IOBase.writelines>.

Do you want a boolean like "append_newlines=True" or a string like "append_string='\n'"

But it only applies if the argument is iterable, right?

That is, it would have no effect on something like:

fl.writelines(3, append_newlines=True)

That raises an exception, and I wouldn't expect that to change.

Assuming so, the parameter would need to have some more appropriate name, like append_newlines_if_iterable.

Personally, I don't think this has any chance of being accepted, but that's me. There are numerous ways to achieve this already, and we don't need another one.

On Tue, Jul 13, 2021 at 9:00 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

As it stands, writelines is consistent with readlines. Both preserve newlines.

indeed. so if this idea is to be done (and there's something to be said for it), I think a similar option should be added to readlines as well -- striping the newline. A couple other notes: This would highlight the whole "a string is an iterable of strings" problem :-( -- should strings be special cased? I think not, that's an issue that Python programmers have to learn at one point or another anyway. As for whether it always puts in a newline, or if you can specify what you want to put in , I vote for the newline -- newlines are not the same on all platforms (though TextIO does translate), but I think it would get a bit confusing if someone explicitly put in "\n| and got "\r\n". And the name IS writeLINES -- so why would anyone expect to use it for anything else -- we still have str.join() after all. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

I've written something like this far too many times: lines = (line.rstrip('\n') for line in open(frame).readlines()) It's not unworkable, but it's definitely common to want the lines without the newlines. The corresponding .writelines() hits me less, but it's still a concern. I slightly shorter and more intuitive spelling would be convenient. On the model of print(), it seems like a 'sep=' argument would make sense, while being backwards compatible. Obviously the default would need to be current behavior. On Tue, Jul 13, 2021, 10:08 AM Christopher Barker <pythonchb@gmail.com> wrote:

On Tue, Jul 13, 2021 at 9:00 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

...

As it stands, writelines is consistent with readlines. Both preserve newlines.

indeed. so if this idea is to be done (and there's something to be said for it), I think a similar option should be added to readlines as well -- striping the newline.

A couple other notes:

This would highlight the whole "a string is an iterable of strings" problem :-( -- should strings be special cased? I think not, that's an issue that Python programmers have to learn at one point or another anyway.

As for whether it always puts in a newline, or if you can specify what you want to put in , I vote for the newline -- newlines are not the same on all platforms (though TextIO does translate), but I think it would get a bit confusing if someone explicitly put in "\n| and got "\r\n".

And the name IS writeLINES -- so why would anyone expect to use it for anything else -- we still have str.join() after all.

-CHB -- Christopher Barker, PhD (Chris)

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TWZHPL... Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Jul 13, 2021 at 09:05:54AM -0700, Christopher Barker wrote:

indeed. so if this idea is to be done (and there's something to be said for it), I think a similar option should be added to readlines as well -- striping the newline.

I don't think that's as useful as you may expect. When processing lines of text, we often want to strip *any* trailing whitespace, not just newlines. So even if you strip the newline, you probably will still need to strip trailing whitespace. So why bother with stripping the newline? I think it will be extremely niche to want one but not the other.

A couple other notes:

This would highlight the whole "a string is an iterable of strings" problem :-( -- should strings be special cased? I think not, that's an issue that Python programmers have to learn at one point or another anyway.

Sorry, have I missed something? How is this relevant? We're talking about a list of strings.

As for whether it always puts in a newline, or if you can specify what you want to put in , I vote for the newline -- newlines are not the same on all platforms (though TextIO does translate), but I think it would get a bit confusing if someone explicitly put in "\n| and got "\r\n".

A precedent is str.splitlines: splitlines(self, /, keepends=False) Return a list of the lines in the string, breaking at line boundaries. Line breaks are not included in the resulting list unless keepends is given and true. except writelines (and readlines) would presumably reverse the default. * readlines default to keeping the newlines * writelines default to not appending newlines

And the name IS writeLINES -- so why would anyone expect to use it for anything else -- we still have str.join() after all.

Repurposing functions to do something different from what the designers imagined is very common. -- Steve

On Tue, Jul 13, 2021 at 08:59:21AM -0700, Guido van Rossum wrote:

Let's leave poor writelines alone. It's an old API, if you want something different, there are a zillion other ways (e.g. print(*x, sep="\n") ).

I wonder how much research the OP did before they claimed "writelines is a very big misnomer to many python developers".

I don't know about research, but the API certainly fools me. I don't consider the delimiter at the end of the line (the newline) to be part of the line, so whenever I used readlines and writelines I am invariably surprised by the fact that writelines requires the newlines to already be there. I'm also surprised that there's a readline but no writeline :-) -- Steve

On Tue, Jul 13, 2021 at 09:54:27AM -0400, Eric V. Smith wrote:

I'm skeptical that people who won't read the documentation for writelines will either read the documentation for writelines2, or intuitively understand how it's different from writelines, or would know there's a kwarg parameter to writelines.

Of course they won't. They'll just go on Twitter to bitch about what a horrible language Python is, because it's not "intuitive", until somebody points them to a few dozen StackOverflow posts that point out how to use it correctly. *wink* In this case I agree that the current API is a little surprising, but it seems to me that adding a kw parameter or a new method is an easy way to solve that. No, people who don't read the docs won't intuit their existence, but so long as *one* person reads the docs, the knowledge will slowly spread via mailing lists, StackOverflow, code reviews, etc.

It seems your proposal would only matter if the argument were a list?

writelines doesn't require a list, it takes any iterable that yields strings. (The docs are misleading: it still says "list".) The current behaviour would have to remain the same, so the items would be written directly, whether or not they end with a newline. With the parameter, writelines would write a newline after each item in the iterable. -- Steve