а то я вот так

a=input() def capitalize(string): b=[] i=0 while i<(len(string)): if i==0: b.append(string[i].upper()) elif string[i] == " ": b.append(string[i]) b.append(string[i+1].upper()) i+=2 continue else: b.append(string[i]) i+=1 return (''.join([str(i) for i in b])) print(capitalize(a))

" ".join(map(str.capitalize, input().split()))

а какой дефолт у str.split()?

Или там не str?

В смысле, дефолт первого аргумента

а какой дефолт у str.split()?

Дефолт - по всем вайтспейсам.

Специальный смысл дефолтного значения None.

Ого. Новости)

Вопрос знатокам: может ли "".join, приняв на вход генератор, сгенерировать выходную строку эффективнее, чем sum, не беря list от входного генератора?

Вопрос знатокам: может ли "".join, приняв на вход генератор, сгенерировать выходную строку эффективнее, чем sum, не беря list от входного генератора?

Смотря как sum реализован

Смотря как sum реализован

Как reduce(lambda x, y: x + y, ...).

Смотря как + сделан

Как питоний строковый плюс.

Для += в cpython оптимизации есть

Вопрос знатокам: может ли "".join, приняв на вход генератор, сгенерировать выходную строку эффективнее, чем sum, не беря list от входного генератора?

sum не может сгенерировать выходную строку :P

Для += в cpython оптимизации есть

Ого, какого рода?

Он работает быстро

sum не может сгенерировать выходную строку :P

Представь, что может) reduce(lambda x, y: x + y, ...)

>>> sum(('a', 'b', 'c')) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str'

:P

Представь, что может) reduce(lambda x, y: x + y, ...)

Ну джойнить в сях всяко быстрее, чем питоновскую лямбду звать

>>> sum(('a', 'b', 'c')) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str'

>>> sum(('a', 'b', 'c'), "") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: sum() can't sum strings [use ''.join(seq) instead]

Ну джойнить в сях всяко быстрее, чем питоновскую лямбду звать

А почему? )

Ну кстати да, нельзя вроде

»> sum(("a", "b", "c"), "") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: sum() can't sum strings [use ''.join(seq) instead]

Потому что питон это медленно

Только поэтому?

Он даже посказывает)

https://rushter.com/blog/python-gil-thread-scheduling/ ?

Если делать тупым плюсом, там переаллокация на каждую строку будет. Джойн может догадаться в 2 раза увеличивать, например

Ну джойнить в сях всяко быстрее, чем питоновскую лямбду звать

быстрее, зато корки в питоне пореже вылетают и buffer overflow

быстрее, зато корки в питоне пореже вылетают и buffer overflow

У меня ни разу не вылетал ни там, ни там

Если делать тупым плюсом, там переаллокация на каждую строку будет. Джойн может догадаться в 2 раза увеличивать, например

Бинго!

А если через +=, то без разницы, скорее всего

У меня ни разу не вылетал ни там, ни там

Ты писал на сях - и у тебя никогда приложение не сваливалось в корку?

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

Не верю)

Ты писал на сях - и у тебя никогда приложение не сваливалось в корку?

Я использовал сишный код цпитона

А если через +=, то без разницы, скорее всего

Это если строка реализована как динамический массив. Что маловероятно.

Я использовал сишный код цпитона

так верю

Это если строка реализована как динамический массив. Что маловероятно.

>>> s = '' >>> for i in range(1000000): ... s += 'a' это меньше секунды работает

Кстати, какой самый быстрый вариант нахождения подстроки?

in?

Кстати, какой самый быстрый вариант нахождения подстроки?

Алгоритмически или в питоне?

В петоне

Я где-то вычитал, что in хуйня

В петоне

in наверное

Я где-то вычитал, что in хуйня

О_о где?

in быстрее, чем find

Чот не верится, что хуйня. Непонятно, с чего бы им в cpython пихать для такой базовой вещи что-то не оптимальное

Я где-то вычитал у Лутца, что in решает половину проблем

https://stackoverflow.com/q/18437798/3606603

У in линейная сложность вроде

В телеге можно редактировать сообщения

И в 3.х оптимизирована до ужаса

У in линейная сложность вроде

А ты хочешь подстроку за O(1) искать?

У in линейная сложность вроде

У find тоже

У find тоже

А разве можно лучше?

А разве можно лучше?

С предпосчетом можно

С предподсчётом можно и за O(1), если хэши предпосчитаны)

С предподсчётом можно и за O(1), если хэши предпосчитаны)

А теперь линия памяти

Вообще, суть вопроса в скобочной последовательности. Без использования стека. Ща покажу. Постоянно думаю, как это можно оптимизировать

ERROR: S client not available

А теперь линия памяти

А не квадрат?

С предподсчётом можно и за O(1), если хэши предпосчитаны)

Считаем хэши для всех строк?

А не квадрат?

Квадрат много, хочу меньше

Для всех подстрок строки, в которой ищем, и для строки, которую ищем

Вот

И это таки не 1, а длина образца

жестоко

Для всех подстрок строки, в которой ищем, и для строки, которую ищем

индекс называется)

жестоко

Зато прикольно

И это таки не 1, а длина образца

Говорю же, если предпосчитаны.

Суфавтомат дает то же самое, но без квадрата памяти и с линейным предпосчетом

Говорю же, если предпосчитаны.

Образец у тебя не бывает предпосчитан

Образец у тебя не бывает предпосчитан

В питоне бывает!

Интересно, можно ли его ускорить

В питоне бывает!

Тогда можно и позиции предпосчитать сразу

Говорю же, если предпосчитаны.

Вообще интересно узнать кейсы, когда это оправдано ?

Тогда можно и позиции предпосчитать сразу

Ну ладно уж, в питоне со строкой в комплекте часто идёт предпосчитанный хэш.

Вообще интересно узнать кейсы, когда это оправдано ?

Например, быстрый поиск по большому документу

Ну ладно уж, в питоне со строкой в комплекте часто идёт предпосчитанный хэш.

Зачем он это сохраняет?

Зачем он это сохраняет?

Потому что частая операция.

Например, быстрый поиск по большому документу

Ну там индексация всяко как-нибудь умнее делается, чем преподсчет хешей всех подстрок

Там суфдерево часто используется

Я чувствую себя тупым, завязывайте

XD

Давайте вернемся к этому алгоритму. Его ускорить можно?

Недавно постили же питонячью магию про строку, у которой увеличивается sys.getsizeof().

Ну там индексация всяко как-нибудь умнее делается, чем преподсчет хешей всех подстрок

Суфдерево, да. Правда, оно находит за О(длина искомой строки), это тебе не О(1) при предпосчитанном хэше!

Давайте вернемся к этому алгоритму. Его ускорить можно?

Зачем?

Зачем?

Ради интереса