' '.join(list)

можно и циклом, но нету смысола

разобрался, благодарю

не знаю

не знаю

lol

' '.join(['a', 'b', 'c']) ты не про это?

У этого метода есть один недостаток - все элементы списка должны быть строкового типа. Есть альтернативный способ вывода списка без скобок и запятых: print(*list, sep=' ')

У этого метода есть один недостаток - все элементы списка должны быть строкового типа. Есть альтернативный способ вывода списка без скобок и запятых: print(*list, sep=' ')

Этот вообще классно подошёл)

У этого метода есть один недостаток - все элементы списка должны быть строкового типа. Есть альтернативный способ вывода списка без скобок и запятых: print(*list, sep=' ')

Оу, не знал, что print так умеет. Четко

Всем доброго времени суток.

Всем доброго времени суток.

nometa.xyz

Вообще это хороший вопрос для обсуждения. @Tishka17 вы, вот, например, запускаете больше одного воркера uwsgi/gunicorn/nginx etc в одном контейнере?

Да, запускаю

Да, запускаю

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

и в целом я не могу сходу придумать аргументов против такого подхода кроме накладных расходов на мастер-процесс

n воркеров это почти один процесс

и в целом я не могу сходу придумать аргументов против такого подхода кроме накладных расходов на мастер-процесс

Может быть, так сложнее на кластере запускать

n воркеров это почти один процесс

ну тогда тоже можно сказать и про supervisord запускающий uwsgi и nginx в одном контейнере

А вот это изврат

Кроме uwsgi, под ним могут быть другие контейнеры

Плюс перезапускать их отдельно ты не сможешь

А вот это изврат

ну не такая уж и большая разница если подумать

Плюс перезапускать их отдельно ты не сможешь

А зачем их отдельно перезапускать?

А зачем их отдельно перезапускать?

Чтобы обновить код, например. Зачем для этого nginx ронять?

Чтобы обновить код, например. Зачем для этого nginx ронять?

Например конфиг nginx'а может поменять вместе с приложением

Например конфиг nginx'а может поменять вместе с приложением

Есть reload

Есть reload

Я новый конфиг как должен попасить в контейнер с nginx'ом?

Я новый конфиг как должен попасить в контейнер с nginx'ом?

Сделать volume, положить в него

нет, volume'ы для этого еще большее зло

как это версионировать?

Пока не вижу минусов

А зачем конфиги на проде версионировать вместе с кодом? Админ при накатывании разберется

Они могут меняться по не зависящим от кода причинам, и что, коммитить все?

Они могут меняться по не зависящим от кода причинам, и что, коммитить все?

конечно коммитить

конечно коммитить

Но не в репу с кодом

Но не в репу с кодом

Да, в репу с кодом

Код для разработчиков, конфиги для админов

а Dockerfile тоже не в репе с кодом должен быть?

Зачем всем знать, по какому пути там сертификат лежит и какой там пароль от базы?

Dockerfile в репе, и он меняется только с кодом

Зачем всем знать, по какому пути там сертификат лежит и какой там пароль от базы?

Ты, видимо сейчас про фронтовые прокси говоришь, да?

Я сейчас говорю про развертывание сайта

Dockerfile в репе, и он меняется только с кодом

Dockerfile это тоже по сути конфиг нужный только для деплоя

т.е. это часть эксплуатации

Это совершенно другой конфиг

И он нужен в том числе для разработки

Возможно, другой, но все же

Деплоят иногда вообще без докера

Я сейчас говорю про развертывание сайта

Ну раз ты сказал про сертификаты. То ssl терминируется на балансировщиках, а они как правило существуют отдельно от веб-серверов, которые уже отдают приложение

Ну раз ты сказал про сертификаты. То ssl терминируется на балансировщиках, а они как правило существуют отдельно от веб-серверов, которые уже отдают приложение

А в базу ходит таки приложение

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

ты же не будешь все это тащить на балансировщики?

А зачем этим приложениям каждому по нгинксу? Сейчас все и так умеют http слушать

А зачем этим приложениям каждому по нгинксу? Сейчас все и так умеют http слушать

Навскидку: чтобы не парсить http чтобы раздавать статику

Я сейчас не про огромные кластеры с тысячами микросервисов, а про стандартные сайты

Я сейчас не про огромные кластеры с тысячами микросервисов, а про стандартные сайты

Если у тебя одно приложение, то да

Там можно себе позволить из балансировщика сразу ходить куда надо

и в целом я не могу сходу придумать аргументов против такого подхода кроме накладных расходов на мастер-процесс

проблема такого подхода в том, что балансировкой нагрузки управляет оркестратор кластера.

можно

А если два, что меняется?

если я правильно понял о чем речь

Начали за здравие, а закончили за хайлоад

А если два, что меняется?

А если два, то у тебя твой единственный nginx должен знать особенности каждого из приложений. А еще проблема с атомарностью возникает

у тебя приложение отдельно, nginx-конфиг отдельно

ERROR: S client not available

и нужно это все как-то синхронизировать

А если два, то у тебя твой единственный nginx должен знать особенности каждого из приложений. А еще проблема с атомарностью возникает

Если там приложение поменялось настолько, что надо конфиги балансирлвщика менять, можно и что-нибудь придумать. Но часто можно накатить сначала одно, потом другое

проблема такого подхода в том, что балансировкой нагрузки управляет оркестратор кластера.

Ты сейчас про то, что 15 контейнеров с один воркером uwsgi эфеективнее, чем 5 контейнеров с 3 воркерами?

Если там приложение поменялось настолько, что надо конфиги балансирлвщика менять, можно и что-нибудь придумать. Но часто можно накатить сначала одно, потом другое

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

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

Если админы общие, почему нет?

Если админы общие, почему нет?

Почему нет что?

вручную синхронизировать изменения?

Почему нельзя влиять на конфиг балансировщика

Ты сейчас про то, что 15 контейнеров с один воркером uwsgi эфеективнее, чем 5 контейнеров с 3 воркерами?

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

Почему нельзя влиять на конфиг балансировщика

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

это будет работать, но поддерживать и управлять этим будет сложно

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

Это для тех у кого многопоточное приложение, а у нас питон

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

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

Подскажите как удалить элементы строки зная номера их позиций?

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

Ребят, есть кто из геймдева? Мне очень сильно нужна ваша помощь. Отпишите в ЛС. Хочу в бота внедрить экономику, чтобы пользователь мог как-то зависать в игре, а не фигней страдать. Сорри за оффтоп

Подскажите как удалить элементы строки зная номера их позиций?

строки immutable. str[:pos] + str[pos+1:]

лучше не удалять элементы строки а составить новую строку

строки immutable. str[:pos] + str[pos+1:]

но удалять возможно?

но удалять возможно?

строки immutable

но удалять возможно?

удоляй

но удалять возможно?

это не удаление, а конкатенация двух срезов - прием, который выглядит как удаление

В PEP8 при переносе строк с операторами рекомендуют бинарный оператор переносить в начало новой строки. А что касается запятых? Не лучше ли их для видимости выносить на новую строчку?

Если админы общие, почему нет?

А еще в кластере одновременно могут работать разные версии одного и того же приложения. Как выходить из такой ситуации когда тебе нужно внести обратнонесомвестимые изменения в nginx-конфиг?

В PEP8 при переносе строк с операторами рекомендуют бинарный оператор переносить в начало новой строки. А что касается запятых? Не лучше ли их для видимости выносить на новую строчку?

Не лучше, следуй pep-8

В PEP8 при переносе строк с операторами рекомендуют бинарный оператор переносить в начало новой строки. А что касается запятых? Не лучше ли их для видимости выносить на новую строчку?

1) да 2) нет

А еще в кластере одновременно могут работать разные версии одного и того же приложения. Как выходить из такой ситуации когда тебе нужно внести обратнонесомвестимые изменения в nginx-конфиг?

если у тебя конфиги специфичные для приложения, то зачем тебе общий инстанс nginx?

Ну вот например, к слову о leading comma vs trailing comma: / error in standard style var a = "ape", b = "bat", c = "cat", d = "dog" e = "elf", f = "fly", g = "gnu", h = "hat", i = "ibu"; // error in comma-first style var a = "ape" , b = "bat" , c = "cat" , d = "dog" e = "elf" , f = "fly" , g = "gnu" , h = "hat" , i = "ibu";

Это не Python, но идея понятна.

А в PEP8 я не нашёл, что leading comma — плохо.

Нет, это уродство