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
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
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 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 2021-07-13 15:11, sandhoners123@gmail.com wrote:
Maybe (to be consistent with other functions like print), end= since 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.
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-c...>
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 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
Ignore me on this, I wasn't focusing on the function at hand. Eric On 7/13/2021 10:18 AM, 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)
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
_______________________________________________ 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/OTRRFI... Code of Conduct: http://python.org/psf/codeofconduct/
-- Eric V. Smith
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 7/13/2021 7:15 AM, sandhoners123@gmail.com wrote:
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'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. It seems your proposal would only matter if the argument were a list? Or does it include tuples and other iterables? If lists, I assume that: fl.writelines2(['a', 'b', 'c']) would produce 3 lines: a b c But what would: fl.writelines2('abc') produce? It's an iterable. Eric
It would produce a\nb\nc\n. Essentially it would put \n after every value gotten from a iterator
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. -- Jonathan
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.
Thank you Paul. I used my default Python, which is Python 3.6. However, with 3.7 and 3.8 I get the same as you. I've promoted you 'works for me' on b.p.o to 'not a bug'. Thank you again. -- Jonathan
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
13.07.21 14:15, sandhoners123@gmail.com пише:
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
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.
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
On Wed, Jul 14, 2021 at 11:22 AM Steven D'Aprano <steve@pearwood.info> wrote:
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.
Breakage has to be justified. The value of readinto1 is more significant than a change to writelines(), which - I'll be honest - is an API that I've never bothered with. It's usually easiest to just write(). But OTOH, the breakage here wouldn't be very significant. In theory, it means adding the functionality to every file-like object. In practice, nobody knows what "file-like object" really means, other than "has that one method of file objects that I'm going to be calling", so if other objects don't have this method or arg, it won't hurt. I'm -0 on this. ChrisA
participants (13)
-
2QdxY4RzWzUUiLuE@potatochowder.com
-
Chris Angelico
-
Christopher Barker
-
David Mertz
-
Eric V. Smith
-
Guido van Rossum
-
Jonathan Fine
-
MRAB
-
Paul Moore
-
sandhoners123@gmail.com
-
Serhiy Storchaka
-
Steven D'Aprano
-
Thomas Güttler