On 10/21/2009 11:47 PM, Carl Banks wrote:
> On Oct 21, 12:46 pm, David C Ullrich <dullr...@sprynet.com> wrote:
>> On Tue, 20 Oct 2009 15:22:55 -0700, Mensanator wrote:
>> > On Oct 20, 1:51 pm, David C Ullrich <dullr...@sprynet.com> wrote:
>> > I'm not saying either behaviour is wrong, it's just not obvious that the
>> > one behaviour doesn't follow from the other and the documentation could
>> > be
>> > a little clearer on this matter. It might make a bit more sense to
>> > actually
>> > mention the slpit(sep) behavior that split() doesn't do.
>>
>> Have you _read_ the docs? They're quite clear on the difference
>> between no sep (or sep=None) and sep=something:
>
> Even if the docs do describe the behavior adequately, he has a point
> that the documents should emphasize the counterintutive split
> personality of the method better.
>
> s.split() and s.split(sep) do different things, and there is no string
> sep that can make s.split(sep) behave like s.split(). That's not
> unheard of but it does go against our typical expectations. It would
> have been a better library design if s.split() and s.split(sep) were
> different methods.
>
> That they are the same method isn't the end of the world but the
> documentation really ought to emphasize its dual nature.
I would also offer that the example
'1,,2'.split(',') returns ['1', '', '2'])
could be improved by including a sep instance at the
beginning or end of the string, like
'1,,2,'.split(',') returns ['1', '', '2', ''])
since that illustrates another difference between the
sep and non-sep cases.
--
http://mail.python.org/mailman/listinfo/python-list
