On 12 Mar 2002 at 19:16, Christian Tismer wrote:
> Gerald S. Williams wrote:
>
> > Christian Tismer wrote:
> >
> >>I'm just translating the Python Pocked Reference the
> >>second time, and I stumbled over this:
> >> "funny".split("")
> >>gives a ValueError: empty separator.
> >>Why this?
> >>
> >
> > I don't know, but I have a patch for stringobject.c and
> > stropmodule.c that gives the behavior you asked for (I
> > haven't done unicodeobject.c yet). Should I post it?
>
>
> Thanks a lot!
> But I think this is not a problem of implementation
> but design. Since "hello".split("") would be the only
> ambiguous case (you can find non-countable infinite
> outputs which would yield the same join), they seem
> to have decided to forbid it.
> I (bummer head) would have choosen the obvious,
> but having to replace the expression by list("hello")
> is just fine with me, and for sure a bit cleaner.
>
> ciao - chris
This topic has come up several times in c.l.py, as recently as a month ago.
Various people proposed what appeared to them to be plausible return values instead of
an exception for 'abc'.split(''):
1. ['a', 'b', 'c']
2. ['', 'a', 'b', 'c', '']
3. ['abc']
4. An infinitely-long list of null strings -- from somebody in a university mathematics
department -- as Python seems to be sprouting singleton objects, maybe we could have
StringAlephNull specifically to be returned from any_string.split(""). Actually, as the
proponent's suggestion was based on naive code for split() which got stuck in a loop at
the *start* of the source string, "".split("") should yield StringAleph(0) and in general
foo.split("") should return StringAleph(len(foo)).
... in other words, plenty of evidence that splitting on a null separator is extremely ill-
definable and the current behaviour should be maintained.
Cheers,
John
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4