This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nascheme
Recipients Alexander Schrijver, barry, docs@python, ezio.melotti, gregory.p.smith, jwilk, lemburg, martin.panter, nascheme, python-dev, r.david.murray, scharron, serhiy.storchaka, terry.reedy, vstinner
Date 2018-10-05.18:13:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1538763188.26.0.545547206417.issue22232@psf.upfronthosting.co.za>
In-reply-to
Content
> Why not simply add a new parameter, to make people who want ASCII linebreaks continue to use .splitlines() ?

That could work but I think in nearly every case you don't want to use splitlines() without supplying the parameter.  So, it seems like a bit of trap for new users.  Worse, because in Python 2, str.splitlines() does what they want, they will do the simple thing which is likely wrong.

If we do stick with just splitlines(), perhaps it should get a 'newline' parameter that mostly matches io.open (i.e. it controls universal newline behavior).  So if you don't want to change behavior, str.splitlines(newline=None) would split as it currently does.  To make it split like io files do, you would have to do newline='\n'.

To me, it seems attractive that:
fp.readlines() == fp.read().iterlines()

You suggestion would make it something like:
fp.readlines() == fp.read().splitlines(newline='\n')

I guess I could live with that but it seems unnecessarily ugly and verbose for what is the most common usage.
History
Date User Action Args
2018-10-05 18:13:08naschemesetrecipients: + nascheme, lemburg, barry, terry.reedy, gregory.p.smith, vstinner, jwilk, ezio.melotti, r.david.murray, docs@python, python-dev, martin.panter, serhiy.storchaka, scharron, Alexander Schrijver
2018-10-05 18:13:08naschemesetmessageid: <1538763188.26.0.545547206417.issue22232@psf.upfronthosting.co.za>
2018-10-05 18:13:08naschemelinkissue22232 messages
2018-10-05 18:13:08naschemecreate