а она в свою очередь опирается на системное tzdata

Как тут использовать прокси? import smtplib toaddr = 'client@yandex.ru' text='Your code 123' server = smtplib.SMTP('smtp.mail.ru',587);server.starttls() server.login(mail,password) server.sendmail(mail,toaddr,text) server.close()

кто в vim могет?

кто в vim могет?

Но зачем :)

кто в vim могет?

Выйти не можешь?

Выйти не можешь?

:x

я просто думал кто подскажет плюшки чем он лучше ide кроме скорости

я просто думал кто подскажет плюшки чем он лучше ide кроме скорости

Ничем

принял

А тут был какой-то холивар на эту тему?

vi предустановлен почти везде и есть даже в busybox

я его юзаю при деплое джанги

и все

при деплое лучше бы вообще никуда не лазить руками, но это мелочи жизни

При завершении программы выполняются абсолютно все блоки finally, или только тот, в try которого была программа в момент завершения?

При завершении программы выполняются абсолютно все блоки finally, или только тот, в try которого была программа в момент завершения?

2е

При завершении программы выполняются абсолютно все блоки finally, или только тот, в try которого была программа в момент завершения?

Каждому блоку try соответствует finally. При выходе из try по любой причине выполняется соответствующий finally. Если ты одновременно из двух try вылетаешь, оба finally сработают. Всякие левые блоки естественно не работают

vi в busybox очень урезанный, аж до невозможности

https://habr.com/ru/post/444594/ - мне интересно, я один не понимаю этого угорания по O-большому?

угорания?

https://habr.com/ru/post/444594/ - мне интересно, я один не понимаю этого угорания по O-большому?

Может ты просто не понимаешь, для чего она?

Ну, уж явно не для применения в программировании

ну да не для программирования

вон выше посмотри, человек жаловался, что у него цикл долго работает

Смотря что ты имеешь в виду под словом программирование. Для того, чтобы сайты верстать, анализ алгоритмов не нужен

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

Хотя нет, анализ алгоримтов при помощи такой нотации

когда ты смотришь на код и говоришь "но это же говно, оно работает за куб!"

"а задача же тривиальная, неужели нельзя сделать за квадрат?"

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

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

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

Слышали ли вы про константу?

естессно

Слышали ли вы про константу?

Слышал. К чему это?

не, понятно, что оценивать константу тоже можно

но просто "вот код, он должен вызываться 100500 раз в секунду"

Слышал. К чему это?

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

когда ты смотришь на код и говоришь "но это же говно, оно работает за куб!"

Почему не сказать "вместо трех вложенных циклов, можно сделать два?"

И будут примеры посложнее?

и ты такой - "ну можно сделать просто за логарифм, но это потребует квадрат памяти, а можно сделать за квадрат, но зато константа памяти"

Что-то в духе, у тебя тут O( n * log n + m * log m + s^3), а ведь можно ..."

и надо просто попробовать то и другое

и ты такой - "ну можно сделать просто за логарифм, но это потребует квадрат памяти, а можно сделать за квадрат, но зато константа памяти"

И тут на помощь приходят бенчмарки

естессно

Потому что правильно высчитать константу у вас не получится

и не надо

Тогда зачем думать в терминах O-большого?

конечно бенчмарки

но бенчмарк не даст готового ответа

И тут на помощь приходят бенчмарки

Дополнительное время для кодинга - проеб по деньгам. Можно подумать, и оценить биг оу

и если бенчмарк говорит "это хреново", то ты начинаешь думать, а можно ли сделать лучше

Дополнительное время для кодинга - проеб по деньгам. Можно подумать, и оценить биг оу

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

Тогда зачем думать в терминах O-большого?

Потому что в 95% О(логН) лучше чем О(н)

и если бенчмарк говорит "это хреново", то ты начинаешь думать, а можно ли сделать лучше

line profiler

Потому что в 95% О(логН) лучше чем О(н)

Пруфы будут? Я вот откровенно говоря, не уверен

"да, тут хреново, потому что квадрат.... а вообще, может есть способ сделать хотя бы за н лог н?... Требует переделать все структуры данных. Пробуем?"

потому что это разговоры, которые я реально регулярно слышу на работе

Пруфы будут? Я вот откровенно говоря, не уверен

Кормен в помощь

Кормен в помощь

У него там есть пруф, где он посчитал все алгоритмы и такой "ну вот, в 95% случаев все ок"? Сомневаюсь

лайн профайлер покажет тебе, что на обработке массива в 1000 элементов ты пробегаешь по некоторой строке миллион раз.

потому что это разговоры, которые я реально регулярно слышу на работе

Страшные люди у вас на работе, я не знаю, мне завидно или нет

лайн профайлер покажет тебе, что на обработке массива в 1000 элементов ты пробегаешь по некоторой строке миллион раз.

И да, в такой момент до меня доходит, что надо переделать алгоритм

У него там есть пруф, где он посчитал все алгоритмы и такой "ну вот, в 95% случаев все ок"? Сомневаюсь

Ору с тебя

А можно было бы сесть и погрустить, но орать оно проще, да. Ведь О-большое для ора всего-то log n?

не, я не понимаю, чего не так в о-большом. Не рокет сайнс же

ты смотришь на код и видишь его о-большое.

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

ты смотришь на код и видишь его о-большое.

Эм .... нет

их надо запускать

Окей

а на всяком эмбеддед оборудовании в дальних полях это бывает делать не очень удобно

Какое будет О-большое от доставания элемента из словаря?

И в догонку, такой же вопрос про добавление элемента в конец обычного списка

формально считается за константу, реально зависит от размера хэша

добавление в конец односвязного списка - линия от длины списка. Циклического - константа

На самом деле, формально - O(m), где m - это максимальное количество коллизий

добавление в конец односвязного списка - линия от длины списка. Циклического - константа

В список питона, который list

На самом деле, формально - O(m), где m - это максимальное количество коллизий

Пруф

константа+время на аллокацию

потому что списки в питоне циклические и из связанных блоков

К тому же, ты понимаешь, что словарь это абстрактная структура данных и ее как следствие нельзя анализировать с помощью О?

На самом деле, формально - O(m), где m - это максимальное количество коллизий

это если при коллизии идет линейный поиск. Но есть другие споосбы

На самом деле, формально - O(m), где m - это максимальное количество коллизий

Эм. Чуть сложнее

К тому же, ты понимаешь, что словарь это абстрактная структура данных и ее как следствие нельзя анализировать с помощью О?

А у вас есть не абстрактные структуры в питоне?

Эм. Чуть сложнее

Окей, еще сложнее

Кстати, не расскажешь как? А то я буду очень долго ковырять код

для словаря там есть где-то логарифмы, но эти логарифмы ограничены сверху какими-то размерами, поэтому "не больше константы"

А у вас есть не абстрактные структуры в питоне?

Что?)

https://m.habr.com/ru/post/247843/

Там хитро коллизии считаются

на дворе ж уже 3.7, а в нём словари упорядочены

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

но я не математик, деталей не знаю

Такое же замечание как у человека выше, походу надо таки читать доку в коде :(

Что?)

Ну, вы же понимаете, что сложность алгоримтов должна как бы складывается? Если вы оцениваете алгоримт сверху, чисто по циклу, то это как-то очень странно