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

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

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

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". On Tue, Jul 13, 2021 at 8:46 AM MRAB <python@mrabarnett.plus.com> wrote:

...

Maybe (to be consistent with other functions like print), end= since

On 2021-07-13 15:11, sandhoners123@gmail.com wrote: that would allow even custom line endings

...

I'm not sure about the name 'end'. The 'print' function has 'end', but it's printed only at the end(!); .writelines would write it after every line. _______________________________________________ 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/2SYIBL... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

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

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.

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

On Tue, Jul 13, 2021 at 10:27:55PM +0300, Serhiy Storchaka wrote:

The writelines method is the part of interface. Adding new parameter or new method to interface is a major breaking change. It will make invalid all existing user code which implements this interface.

I think that statement is a bit strong. How will it break existing code? The code will still work exactly the same as before. We added the BufferedIOBase.readinto1 method in Python 3.5, before that we added 'x' mode and `opener=None` parameter to FileIO in 3.3. https://docs.python.org/3/library/io.html#io.BufferedIOBase.readinto1 https://docs.python.org/3/library/io.html#io.FileIO In 3.7 we allowed the BytesIO.read1 size parameter to be optional: https://docs.python.org/3/library/io.html#io.BytesIO.read1 There are other changes to the IO interfaces through to Python 3.7. If that didn't break code, I don't see why this change would. I think that adding a new method or a keyword-only arg to writelines in 3.11 would be fine. -- Steve