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 barry
Recipients abarry, barry, gvanrossum, mrabarnett, rhettinger, serhiy.storchaka, syeberman, veky
Date 2016-12-12.15:32:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20161212103232.3848855f@subdivisions.wooz.org>
In-reply-to <1481523500.99.0.428915472374.issue28937@psf.upfronthosting.co.za>
Content
I really appreciate all the feedback.  Here are some thoughts.

I'm well aware of the filter(), re, and other options, and certainly those can
be made to work, but they're non-obvious.  The reason I suggested an
enhancement to str.split() is because I've seen the replace().split() being used
far too often, and what I think is happening is that people take the most
natural path to accomplish their goals: they know they just want to do a
simple string split on a token (usually one character) so they start out with
the obvious str.split(',') or whatever.  Then they notice that it doesn't work
consistent with their mental model in some corner cases.

The next common step isn't from there to filter() or re.  The former isn't a
well-known API and the latter is viewed as "too complex".  Their next mental
step is "oh, so providing a sep has different behavior that I don't want, so
I'll just replace the comma with a space and now don't have to provide sep".
And now str.split() does what they want.  Done.  Move along.

I do wish the str.split() API was consistent w.r.t. to sep=None, but it's what
we have and is a very well known API.

@rhettinger: I'm of mixed opinion on it too!  I really wanted to get this in
the tracker and see if we could come up with something better, but so far I
still like `prune` the best.

@ebarry: Thanks for the draft docs, but that's not how I think about this.
I'd be utilitarian and get right to the point, e.g.:

"""
The value of `prune` controls whether empty strings are removed from the
resulting list.  The default value (None) says to use the default behavior,
which for backward compatibility reasons is different whether sep is None or
not (see above).  Regardless of the value of sep, when prune is True empty
strings are removed and when prune is False they are not.
"""

So @mrabarnett, +1 on the suggested defaults.

Lastly, as for Guido's admonition against boolean arguments, I would make
prune a keyword-only argument, so that forces the code to be readable and
should alleviate those concerns.  The trade-off is the extra typing, but
that's actually besides the point.  The win here is that the solution is
easily discoverable and avoids the intermediate string object.
History
Date User Action Args
2016-12-12 15:32:36barrysetrecipients: + barry, gvanrossum, rhettinger, syeberman, mrabarnett, serhiy.storchaka, veky, abarry
2016-12-12 15:32:35barrylinkissue28937 messages
2016-12-12 15:32:35barrycreate