The best answers to the question “Why is it string.join(list) instead of list.join(string)?” in the category Dev.
This has always confused me. It seems like this would be nicer:
my_list = ["Hello", "world"] print(my_list.join("-")) # Produce: "Hello-world"
my_list = ["Hello", "world"] print("-".join(my_list)) # Produce: "Hello-world"
Is there a specific reason it is like this?
This was discussed in the String methods… finally thread in the Python-Dev achive, and was accepted by Guido. This thread began in Jun 1999, and
str.join was included in Python 1.6 which was released in Sep 2000 (and supported Unicode). Python 2.0 (supported
str methods including
join) was released in Oct 2000.
- There were four options proposed in this thread:
joinas a built-in function
- Guido wanted to support not only
tuples, but all sequences/iterables.
seq.reduce(str)is difficult for newcomers.
seq.join(str)introduces unexpected dependency from sequences to str/unicode.
join()as a built-in function would support only specific data types. So using a built-in namespace is not good. If
join()supports many datatypes, creating an optimized implementation would be difficult, if implemented using the
__add__method then it would ve
- The separator string (
sep) should not be omitted. Explicit is better than implicit.
Here are some additional thoughts (my own, and my friend’s):
- Unicode support was coming, but it was not final. At that time UTF-8 was the most likely about to replace UCS2/4. To calculate total buffer length of UTF-8 strings it needs to know character coding rule.
- At that time, Python had already decided on a common sequence interface rule where a user could create a sequence-like (iterable) class. But Python didn’t support extending built-in types until 2.2. At that time it was difficult to provide basic
iterableclass (which is mentioned in another comment).
Guido’s decision is recorded in a historical mail, deciding on
Funny, but it does seem right! Barry, go for it…
Guido van Rossum
It’s because any iterable can be joined (e.g, list, tuple, dict, set), but its contents and the “joiner” must be strings.
'_'.join(['welcome', 'to', 'stack', 'overflow']) '_'.join(('welcome', 'to', 'stack', 'overflow'))
Using something other than strings will raise the following error:
TypeError: sequence item 0: expected str instance, int found
I agree that it’s counterintuitive at first, but there’s a good reason. Join can’t be a method of a list because:
- it must work for different iterables too (tuples, generators, etc.)
- it must have different behavior between different types of strings.
There are actually two join methods (Python 3.0):
>>> b"".join <built-in method join of bytes object at 0x00A46800> >>> "".join <built-in method join of str object at 0x00A28D40>
If join was a method of a list, then it would have to inspect its arguments to decide which one of them to call. And you can’t join byte and str together, so the way they have it now makes sense.
join() method is in the string class, instead of the list class?
I agree it looks funny.
Historical note. When I first learned
Python, I expected join to be a method
of a list, which would take the
delimiter as an argument. Lots of
people feel the same way, and there’s
a story behind the join method. Prior
to Python 1.6, strings didn’t have all
these useful methods. There was a
separate string module which contained
all the string functions; each
function took a string as its first
argument. The functions were deemed
important enough to put onto the
strings themselves, which made sense
for functions like lower, upper, and
split. But many hard-core Python
programmers objected to the new join
method, arguing that it should be a
method of the list instead, or that it
shouldn’t move at all but simply stay
a part of the old string module (which
still has lots of useful stuff in it).
I use the new join method exclusively,
but you will see code written either
way, and if it really bothers you, you
can use the old string.join function
— Mark Pilgrim, Dive into Python