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 <[email protected]>
<http://bugs.python.org/issue15554>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
