I am certain this was proposed many times, but still - why it is rejected? "real man don't use spaces".split().join('+').upper() instead of '+'.join("real man don't use spaces".split()).upper() The class purity (not being dependent from objects of other class) is not an argument here: string.join() produces list, why list.join() couldn't produce strings? The impedance mismatch can be, but it is a pain already and string.join() doesn't help: that means you still get exception when trying to join lists with no strings inside Can practicality still beat purity in this case?
Le 12/05/2012 10:21, anatoly techtonik a écrit :
Hi, I’m not sure what you mean by "class purity", but the argument against this is practical: list.join would work but we want to join iterables, not just lists. bytes.join and str.join accept any iterable (including user-defined ones), while not every iterable would have a join method. Having the burden of defining join on user-defined string-like types (not very common) is better than on user-defined iterables (more common). Also, a "string-like" already needs many methods while __iter__ is enough to make an iterable. -- Simon Sapin
On Sat, May 12, 2012 at 11:21:17AM +0300, anatoly techtonik <techtonik@gmail.com> wrote:
I am certain this was proposed many times
Thousands.
string.join() produces list, why list.join() couldn't produce strings?
string.split() produces list. There is no list.join() because list is only one of many containers. Should tuple has its own .join() method? What about other containers? iterables? generators? string.join() can accept any iterable, not only a list. That's the explanation why it's preferred.
that means you still get exception when trying to join lists with no strings inside
In what way do you expect list.join(string) would help? Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 5/21/2012 10:27 AM, Boris Borcic wrote:
It the separator were a mandatory argument for .split, then that would be possible, not not with it being optional, and therefore the second argument.
' '.join(' real men usE SPAces and tabs'.split()) 'real men usE SPAces and tabs'
is a handy way to clean up whitespace -- Terry Jan Reedy
On Wed, May 23, 2012 at 7:50 AM, Boris Borcic <bborcic@gmail.com> wrote:
The inconsistency that bugs me is the difference in split behavior between languages. Switching between languages means I have to constantly double check this. What is consistent is that you call string.split(separator) rather than separator.split(string) so changing that doesn't seem at all beneficial. Python split has an optional *maxsplit* parameter: If maxsplit is given, at most maxsplit splits are done (thus, the list will have *at most maxsplit+1* elements). The remainder of the string after the last matched separator is included in the last part. Java split has an optional integer *limit* parameter: ... the pattern will be applied at most limit - 1 times, the array's length will be *no greater than limit* ... The remainder of the string after the last matched separator is included in the last part. C# split has an optional *count* parameter: The maximum number of substrings to return. The remainder of the string after the last matched separator is included in the last part. Ruby split has an optional limit parameter: If limit is a positive number, *at most that number of fields* will be returned. The remainder of the string after the last matched separator is included in the last part. Javascript has an optional limit parameter: It returns *at most limit* parts. The remainder of the string after the last matched separator is *discarded*. And I'm not mentioning the differences in how the separator parameter is interpreted. :-) --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Le 12/05/2012 10:21, anatoly techtonik a écrit :
Hi, I’m not sure what you mean by "class purity", but the argument against this is practical: list.join would work but we want to join iterables, not just lists. bytes.join and str.join accept any iterable (including user-defined ones), while not every iterable would have a join method. Having the burden of defining join on user-defined string-like types (not very common) is better than on user-defined iterables (more common). Also, a "string-like" already needs many methods while __iter__ is enough to make an iterable. -- Simon Sapin
On Sat, May 12, 2012 at 11:21:17AM +0300, anatoly techtonik <techtonik@gmail.com> wrote:
I am certain this was proposed many times
Thousands.
string.join() produces list, why list.join() couldn't produce strings?
string.split() produces list. There is no list.join() because list is only one of many containers. Should tuple has its own .join() method? What about other containers? iterables? generators? string.join() can accept any iterable, not only a list. That's the explanation why it's preferred.
that means you still get exception when trying to join lists with no strings inside
In what way do you expect list.join(string) would help? Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On 5/21/2012 10:27 AM, Boris Borcic wrote:
It the separator were a mandatory argument for .split, then that would be possible, not not with it being optional, and therefore the second argument.
' '.join(' real men usE SPAces and tabs'.split()) 'real men usE SPAces and tabs'
is a handy way to clean up whitespace -- Terry Jan Reedy
On Wed, May 23, 2012 at 7:50 AM, Boris Borcic <bborcic@gmail.com> wrote:
The inconsistency that bugs me is the difference in split behavior between languages. Switching between languages means I have to constantly double check this. What is consistent is that you call string.split(separator) rather than separator.split(string) so changing that doesn't seem at all beneficial. Python split has an optional *maxsplit* parameter: If maxsplit is given, at most maxsplit splits are done (thus, the list will have *at most maxsplit+1* elements). The remainder of the string after the last matched separator is included in the last part. Java split has an optional integer *limit* parameter: ... the pattern will be applied at most limit - 1 times, the array's length will be *no greater than limit* ... The remainder of the string after the last matched separator is included in the last part. C# split has an optional *count* parameter: The maximum number of substrings to return. The remainder of the string after the last matched separator is included in the last part. Ruby split has an optional limit parameter: If limit is a positive number, *at most that number of fields* will be returned. The remainder of the string after the last matched separator is included in the last part. Javascript has an optional limit parameter: It returns *at most limit* parts. The remainder of the string after the last matched separator is *discarded*. And I'm not mentioning the differences in how the separator parameter is interpreted. :-) --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
participants (6)
-
anatoly techtonik -
Boris Borcic -
Bruce Leban -
Oleg Broytman -
Simon Sapin -
Terry Reedy