Python join: why is it string.join(list) instead of list.join(string)?
This has always confused me. It seems like this would be nicer:
my_list = ["Hello", "world"]
print my_list.join("-")
# Produce: "Hello-world"
Than this:
my_list = ["Hello", "world"]
print "-".join(my_list)
# Produce: "Hello-world"
Is there a specific reason it is like this?
It's because any iterable can be joined, not just lists, but the result and the "joiner" are always strings.
EG:
import urllib2
print 'n############n'.join(
urllib2.urlopen('http://data.stackexchange.com/users/7095'))
Because the join() method is in the string class, instead of the list class?
I agree it looks funny.
See http://www.faqs.org/docs/diveintopython/odbchelper_join.html:
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 instead.
--- Mark Pilgrim, Dive into Python
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.
str.join(seq) seq.join(str) seq.reduce(str) join as a built-in function list s, tuple s, but all sequences/iterables. seq.reduce(str) is difficult for new-comers. 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 optimized implementation would be difficult, if implemented using the __add__ method then it's O(n²). sep ) should not be omitted. Explicit is better than implicit. There are no other reasons offered in this thread.
Here are some additional thoughts (my own, and my friend's):
Guido's decision is recorded in a historical mail, deciding on str.join(seq) :
Funny, but it does seem right! Barry, go for it...
--Guido van Rossum
上一篇: 在LINQ中不区分大小写的字符串比较