Barry A. Warsaw added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28937> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com