Chris Jerdonek added the comment: > in the patch it now sounds like you are saying that ''.splitlines() does not > return the same result as ''.split() when in fact it does.
The two differences occur only when split() is passed a separator. split() uses a different algorithm when no separator is specified. For example, for the empty string case: >>> ''.splitlines() [] >>> ''.split() [] >>> ''.split('\n') [''] That is why I used the phrase "Unlike split() when passed a separator" in the patch: + Unlike :meth:`~str.split` when passed a separator, this method returns + an empty list for the empty string, and a terminal line break does not I will change the language in the patch to parallel split()'s documentation more closely, to emphasize and make this distinction clearer: "when passed a separator" -> "when a delimiter string *sep* is given". > I would also prefer that the "differences" discussion come in the separate > paragraph after the specification of the behavior of the function, Good point. I agree with you. That occurred to me while drafting the patch, but I was hesitant to change the existing structure too much. In the updated patch I am attaching, I have also made that change. Thanks a lot for reviewing! ---------- Added file: http://bugs.python.org/file26707/issue-15554-3.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15554> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com