R. David Murray <rdmur...@bitdance.com> added the comment: No apologies needed, but you probably aren't going to like the answer :)
First of all, a change like you propose would be unlikely to be accepted since it would create considerable backward-compatibility pain. That aside, however, splitlines and split are not meant to be parallel. They do two very different jobs. splitlines is *line* oriented, and lines are understood to end with line ends. The file equivalent of "" has length zero, and the unix 'wc' command reports it has having 0 lines. A file containing "derp\n' is reported by wc to have one line, not two. Files without a final line end are arguably broken, but all good tools accept that final line as a line, though some complain about it. (And other tools break in various odd ways.) If you want something parallel to split that handles line ends 'universally', try re.split with an appropriate regex. ---------- nosy: +r.david.murray priority: -> normal resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7638> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
