Это всегда смущало меня. Кажется, что это будет лучше

my_list = ["Hello", "world"]
print(my_list.join("-"))
# Produce: "Hello-world"

Чем это:

my_list = ["Hello", "world"]
print("-".join(my_list))
# Produce: "Hello-world"

Есть ли конкретная причина, по которой это так?

Это потому, что любая итерация может быть объединена (например, list, tuple, dict, set), но результат и "joiner" должны быть строками.

Например:

'_'.join(['welcome', 'to', 'stack', 'overflow'])
'_'.join(('welcome', 'to', 'stack', 'overflow'))

'welcome_to_stack_overflow'

Использование чего-то другого, кроме строк, вызовет следующую ошибку:

Ошибка типа: элемент последовательности 0: ожидаемый экземпляр str, int найдено

Это обсуждалось в методах String ... наконец-то в Python-Dev achive, и было принято Гвидо. Эта тема началась в июне 1999 года и str.joinбыла включена в Python 1.6, выпущенный в сентябре 2000 года (и поддерживающий Unicode). Python 2.0 ( strвключая поддерживаемые методы join) был выпущен в октябре 2000 года.

• В этой теме было предложено четыре варианта:
  • str.join(seq)
  • seq.join(str)
  • seq.reduce(str)
  • join как встроенная функция
• Гвидо хотел поддерживать не только lists, tuples, но и все последовательности / итерации.
• seq.reduce(str) сложно для новичков.
• seq.join(str) вводит неожиданную зависимость от последовательностей в str / unicode.
• join()так как встроенная функция будет поддерживать только определенные типы данных. Таким образом, использование встроенного пространства имен не хорошо. Если join()поддерживается много типов данных, создание оптимизированной реализации будет затруднено, если реализовано с использованием __add__метода, то это O (n²).
• Разделитель string ( sep) не должен быть опущен. Явное лучше, чем неявное.

В этой теме нет других причин.

Вот некоторые дополнительные мысли (мои собственные и моего друга):

• Поддержка Unicode приходила, но она не была окончательной. В то время UTF-8, скорее всего, собирался заменить UCS2 / 4. Для вычисления общей длины буфера строк UTF-8 необходимо знать правило кодирования символов.
• В то время Python уже определился с общим правилом интерфейса последовательностей, в котором пользователь мог бы создать подобный последовательности (итеративный) класс. Но Python не поддерживал расширение встроенных типов до 2.2. В то время было трудно предоставить базовый итеративный класс (который упоминается в другом комментарии).

Решение Гвидо записывается в историческом письме , решая str.join(seq):

Забавно, но это кажется правильным! Барри,
дерзай ... - Гидо ван Россум

Потому что join()метод находится в строковом классе, а не в списке класса?

Я согласен, это выглядит смешно.

См. Http://www.faqs.org/docs/diveintopython/odbchelper_join.html :

Историческая справка.Когда я впервые изучил Python, я ожидал, что join будет методом списка, который будет принимать разделитель в качестве аргумента. Многие люди чувствуют то же самое, и за методом объединения есть история. До Python 1.6 у строк не было всех этих полезных методов. Был отдельный строковый модуль, который содержал все строковые функции; каждая функция взяла строку в качестве первого аргумента. Функции считались достаточно важными, чтобы помещать их в сами строки, что имело смысл для таких функций, как lower, upper и split. Но многие злостные программисты на Python возражали против нового метода соединения, утверждая, что он должен быть методом списка, или что он вообще не должен двигаться, а просто оставаться частью старого строкового модуля (в котором все еще много полезных вещей в нем).

--- Марк Пилигрим, Погрузись в Питона

Я согласен, что сначала это нелогично, но есть веская причина. Присоединение не может быть методом списка, потому что:

• он также должен работать для разных итераций (кортежей, генераторов и т. д.)
• он должен иметь разное поведение между разными типами строк.

На самом деле есть два метода соединения (Python 3.0):

>>> b"".join
<built-in method join of bytes object at 0x00A46800>
>>> "".join
<built-in method join of str object at 0x00A28D40>

Если объединение является методом списка, то ему придется проверять свои аргументы, чтобы решить, какой из них вызывать. И вы не можете объединить байты и str вместе, поэтому то, что у них есть, теперь имеет смысл.

Почему это string.join(list)вместо list.join(string)?

Это потому, что joinэто «строковый» метод! Создает строку из любого итератора. Если мы поместим метод в списки, что делать, когда у нас есть итерации, которые не являются списками?

Что делать, если у вас есть набор строк? Если бы это был listметод, вам пришлось бы приводить каждый такой итератор строк как listпрежде, чем вы могли бы объединить элементы в одну строку! Например:

some_strings = ('foo', 'bar', 'baz')

Давайте свернем наш собственный метод соединения со списком:

class OurList(list): 
    def join(self, s):
        return s.join(self)

И чтобы использовать его, обратите внимание, что мы должны сначала создать список из каждой итерации, чтобы объединить строки в эту итерацию, тратя впустую и память, и вычислительную мощность:

>>> l = OurList(some_strings) # step 1, create our list
>>> l.join(', ') # step 2, use our list join method!
'foo, bar, baz'

Итак, мы видим, что мы должны добавить дополнительный шаг, чтобы использовать наш метод списка, вместо того, чтобы просто использовать метод встроенной строки:

>>> ' | '.join(some_strings) # a single step!
'foo | bar | baz'

Предупреждение о производительности для генераторов

Алгоритм, который Python использует для создания окончательной строки, str.joinфактически должен дважды передавать итеративное значение, поэтому, если вы предоставите ему выражение генератора, он должен сначала материализовать его в список, прежде чем сможет создать окончательную строку.

Таким образом, хотя обход генераторов обычно лучше, чем списки, str.joinисключение:

>>> import timeit
>>> min(timeit.repeat(lambda: ''.join(str(i) for i in range(10) if i)))
3.839168446022086
>>> min(timeit.repeat(lambda: ''.join([str(i) for i in range(10) if i])))
3.339879313018173

Тем не менее, эта str.joinоперация все еще семантически является «строковой» операцией, поэтому все же имеет смысл иметь ее на strобъекте, а не на других итерациях.

Думайте об этом как о естественной ортогональной операции разделения.

Я понимаю, почему это применимо к чему-либо повторяемому и поэтому не может быть легко реализовано только в списке.

Для удобства чтения я хотел бы видеть это на языке, но я не думаю, что это на самом деле выполнимо - если бы итеративность была интерфейсом, то его можно было бы добавить к интерфейсу, но это просто соглашение, и поэтому нет никакого центрального способа добавьте его в набор вещей, которые можно повторять.

Прежде всего потому, что результатом someString.join()является строка.

Последовательность (список, кортеж или что-то еще) не появляется в результате, просто строка. Поскольку результатом является строка, это имеет смысл как метод строки.

- в "-". join (my_list) объявляет, что вы конвертируете в строку из соединяемых элементов список. Он ориентирован на результат (просто для удобства памяти и понимания)

Я делаю исчерпывающую таблицу для Methods_of_string для вашей справки.

string_methonds_44 = {
    'convert': ['join','split', 'rsplit','splitlines', 'partition', 'rpartition'],
    'edit': ['replace', 'lstrip', 'rstrip', 'strip'],
    'search': ['endswith', 'startswith', 'count', 'index', 'find','rindex', 'rfind',],
    'condition': ['isalnum', 'isalpha', 'isdecimal', 'isdigit', 'isnumeric','isidentifier',
                  'islower','istitle', 'isupper','isprintable', 'isspace', ],
    'text': ['lower', 'upper', 'capitalize', 'title', 'swapcase',
             'center', 'ljust', 'rjust', 'zfill', 'expandtabs','casefold'],
    'encode': ['translate', 'maketrans', 'encode'],
    'format': ['format', 'format_map']}

Оба не хороши.

string.join (xs, delimit) означает, что строковый модуль знает о существовании списка, о котором он не знает, поскольку строковый модуль работает только со строками.

list.join (delimit) немного лучше, потому что мы так привыкли к тому, что строки являются фундаментальным типом (и, говоря языком, они есть). Однако это означает, что join должен отправляться динамически, потому что в произвольном контексте a.split("\n")компилятор python может не знать, что такое a, и должен будет искать его (аналогично vtable lookup), что дорого, если вы делаете это много раз.

если компилятор времени выполнения Python знает, что список является встроенным модулем, он может пропустить динамический поиск и напрямую зашифровать намерение в байт-код, тогда как в противном случае ему необходимо динамически разрешить «соединение» из «а», которое может занимать несколько уровней наследования за вызов (поскольку между вызовами значение соединения могло измениться, потому что python является динамическим языком).

к сожалению, это абсолютный недостаток абстракции; Независимо от того, какую абстракцию вы выберете, ваша абстракция будет иметь смысл только в контексте проблемы, которую вы пытаетесь решить, и поэтому вы никогда не сможете получить последовательную абстракцию, которая не станет несовместимой с основными идеологиями, когда вы начнете склеивать их. вместе, не оборачивая их в соответствии с вашей идеологией. Зная это, подход python более гибок, поскольку он дешевле, и вам нужно платить больше, чтобы он выглядел «лучше», либо создавая свою собственную обертку, либо свой собственный препроцессор.

Переменные my_listи "-"являются объектами. В частности, они являются экземплярами классов listи str, соответственно. joinФункция принадлежит к классу str. Таким образом, синтаксис "-".join(my_list)используется, потому что объект "-"принимает my_listв качестве входных данных.