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 chris.jerdonek
Recipients chris.jerdonek, docs@python, jcea, ncoghlan, pitrou, r.david.murray, terry.reedy
Date 2012-08-06.05:01:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1344229303.88.0.945913987929.issue15554@psf.upfronthosting.co.za>
In-reply-to
Content
> 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!
History
Date User Action Args
2012-08-06 05:01:44chris.jerdoneksetrecipients: + chris.jerdonek, terry.reedy, jcea, ncoghlan, pitrou, r.david.murray, docs@python
2012-08-06 05:01:43chris.jerdoneksetmessageid: <1344229303.88.0.945913987929.issue15554@psf.upfronthosting.co.za>
2012-08-06 05:01:43chris.jerdoneklinkissue15554 messages
2012-08-06 05:01:42chris.jerdonekcreate