[Python-ideas] [...].join(sep)

[anatoly techtonik]

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?
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas

[Oleg Broytman]

On Sat, May 12, 2012 at 11:21:17AM +0300, anatoly techtonik <tech...@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/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.

[Simon Sapin]

Le 12/05/2012 10:21, anatoly techtonik a écrit :
> 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?

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

[Boris Borcic]

anatoly techtonik wrote:
> 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()

IMO this should really be :

'+'.join(' '.split("real man don't use spaces")).upper()

[Terry Reedy]

On 5/21/2012 10:27 AM, Boris Borcic wrote:
> anatoly techtonik wrote:
>> 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()
>
> IMO this should really be :
>
> '+'.join(' '.split("real man don't use spaces")).upper()

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.

>>> ' real men usE SPAces and tabs'.split()
['real', 'men', 'usE', 'SPAces', 'and', 'tabs']
>>> ' real men usE SPAces and tabs'.split(' ')
['', 'real', '', 'men', '', 'usE', 'SPAces', '', '', 'and', '\t', 'tabs']

>>> ' '.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

[Boris Borcic]

Terry Reedy wrote:
> On 5/21/2012 10:27 AM, Boris Borcic wrote:
>> anatoly techtonik wrote:
>>> 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()
>>
>> IMO this should really be :
>>
>> '+'.join(' '.split("real man don't use spaces")).upper()
>
> 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.
>
> >>> ' real men usE SPAces and tabs'.split()
> ['real', 'men', 'usE', 'SPAces', 'and', 'tabs']
> >>> ' real men usE SPAces and tabs'.split(' ')
> ['', 'real', '', 'men', '', 'usE', 'SPAces', '', '', 'and', '\t', 'tabs']
>
> >>> ' '.join(' real men usE SPAces and tabs'.split())
> 'real men usE SPAces and tabs'
>
> is a handy way to clean up whitespace
>

Kind of beside the point, which is that the desire to repair the inconsistency
between split and join has a better prospect at the split side of things than at
the join side of things. The problems at the split side of things are
comparatively minor.

[Bruce Leban]

On Wed, May 23, 2012 at 7:50 AM, Boris Borcic <bbo...@gmail.com> wrote:

Kind of beside the point, which is that the desire to repair the inconsistency between split and join has a better prospect at the split side of things than at the join side of things. The problems at the split side of things are comparatively minor.

 

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