I think string.split(list) probably won't do what people expect either. Here's what I would expect it to do:<br><br><div style="margin-left: 40px;">>>> '1 (123) 456-7890'.split([' ', '(', ')', '-'])<br>
['1', '', '123', '', '456', '7890']<br></div><br>but what you probably want is:<br><br><div style="margin-left: 40px;">>>>re.split(r'[ ()-]*', '1 (123) 456-7890')<br>
['1', '123', '456', '7890']<br></div><br>using allows you to do that and avoids ambiguity about what it does.<br><br>--- Bruce<br><br><div class="gmail_quote">On Thu, Dec 11, 2008 at 3:58 PM, Ron Adam <span dir="ltr"><<a href="mailto:rrr@ronadam.com">rrr@ronadam.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<a href="mailto:skip@pobox.com" target="_blank">skip@pobox.com</a> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    Guido> Which of the two would you choose for all? The empty string is the<br>
    Guido> only reasonable behavior for split-with-argument, it is the logical<br>
    Guido> consequence of how it behaves when the string is not empty. E.g.<br>
    Guido> "x:y".split(":") -> ["x", "y"], "x::y".split(":") -> ["x", "", "y"],<br>
    Guido> ":".split(":") -> ["", ""]. OTOH split-on-whitespace doesn't behave<br>
    Guido> this way; it extracts the non-empty non-whitespace-containing<br>
    Guido> substrings.<br>
<br>
In my feeble way of thinking I go from something which evaluates to false to<br>
something which doesn't. It's almost like making matter out of empty space:<br>
<br>
    bool("") -> False<br>
    bool("".split()) -> False<br>
    bool("".split("n")) -> True<br>
<br>
    Guido> If anything it's wrong, it's that they share the same name. This<br>
    Guido> wasn't always the case. Do you really want to go back to .split()<br>
    Guido> and .splitfields(sep)?<br>
<br>
That might be preferable.  The same method having such strikingly different<br>
behavior throws me every time I try splitting a possibly empty string with a<br>
non-whitespace character.  It's a relatively uncommon case.  Most of the<br>
time when you split a string with a non-whitespace character I think you<br>
know that the input can't be empty.<br>
<br>
Skip<br>
</blockquote>
<br>
<br></div>
It looks like there are several behaviors involved in split, and you want to split those behaviors out.<br>
<br>
<br>
<br>
Behaviors of string split:<br>
<br>
<br>
1. Split on white space chrs by giving no argument.<br>
<br>
This has the effect of splitting on multiple characters. Strings with multiple white space characters are not multiply split.<br>
<br>
>>> '       '.split()<br>
[]<br>
>>> ' \t\n'.split()<br>
[]<br>
<br>
<br>
<br>
2. Split on word by giving an argument. (A word can be one char.)<br>
<br>
In this case, the split is strict and does not combine/remove null string results.<br>
<br>
>>> '       '.split(' ')<br>
['', '', '', '', '', '', '', '']<br>
>>> ' \t\n'.split(' ')<br>
['', '\t\n']<br>
<br>
<br>
There doesn't seem to be an obvious way to split on different characters.<br>
<br>
<br>
A new to python programmer might try:<br>
<br>
>>> '1 (123) 456-7890'.split(' ()-')<br>
['1 (123) 456-7890']<br>
<br>
Expecting: ['1', '123', '456', '7890']<br>
<br>
<br>
>>> '1 (123) 456-7890'.split([' ', '(', ')', '-'])<br>
Traceback (most recent call last):<br>
  File "<stdin>", line 1, in <module><br>
TypeError: expected a character buffer object<br>
<br>
<br>
When I needed to split on multiple chars other than the default white space, I have used .replace() to replace different splitting character with one single char sequence which I could then split on.<br>
<br>
<br>
It might be nice to have a .splitonchars() version of split with the default being whitespace chars, and an argument to specify other multiple characters to split on.<br>
<br>
The other behavior could be called .splitonwords(arg). The .splitonwords() method could possibly also accept a list of words.<br>
<br>
<br>
That leaves the possibility to leave the current .split() behavior alone and would not break current code.<br>
<br>
And alternately these could be functions in the string module.  In that case the current .split() could just continue to exist as is.<br>
<br>
I find the name 'splitfields' to not be as intuitive as 'splitonwords' and 'splitonchars'.   While both of those require more letters to type than split, they are more readable, and when you do need the capability of splitting on more than one char or word, they are far shorter and less prone to errors than rolling your own function.<br>
<font color="#888888">
<br>
Ron</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br>