Зачем Python?

вы отрицаете, что имели место быть множественные факты переписывания (в какой-то определенный момент времени) отдельных частей во многих проектах на Си, Java и Go? или не считаете это аргументом в пользу моего тезиса - что «на хайлоаде производительность ЯП тоже важна» (хотя, естественно и не везде, и не всегда очень сильно важна).

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

и здесь речь идет об этих материалах: Python'e, PHP, etc. мне видится Python не оптимальным решением, в том числе и из-за производительности. вы же видимо так не считаете. у вас свой взгляд на строительство и бизнес) тут уже субъективизм.

Ну мне недавно такое было нужно. Я сделал модуль, в нем декоратор, в котором задаются условия для match`а. И кучу функций в него завернул, так что в зависимости от аргумента вызывается нужная. Можно было бы сделать класс, с методами, условия запихнуть в docstring или typehint и сделать у него какой-нибудь __call__ который его разбирает.

Я что-то сказал про отсутствие switch в питоне, а ты ответил «и слава богу» или что-то в этом роде. Не нашел. Могу и ошибаться, но по-моему было.

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

Твой пример полная дичь. Для разных action`ов должны быть отдельные функции, вот как это выглядит по-нормальному https://www.django-rest-framework.org/api-guide/viewsets/

if (request('action') == 'do1') {
    //
} else if (request('action') == 'do2') {
    //
} else if (request('action') == 'do3') {
    //
} else {
    //
}

action = request('action')
if action == 'do1':
    ...
elif action == 'do2':
    ...
elif action == 'do3':
    ...
else:
    ...

class Foo:
    def do(self, action):
       if do in ('do1', 'do2', 'do3'):
           getattr(self, action)()
    ...
         

3 столпа ООП для питонистов - «придирка к словам»? ну ок, no comments.

В питоне есть инкапсуляция, наследование и полиморфизм. Хочешь опровергнуть — пиши ясно, что.

А сегодня руби никому не нужен.

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

Можно писать код без switch и без множественного if.

Можно, конечно. Можно и на брейнфаке писать, если не интересует ничего, кроме «можно».

Интересует ясность кода, простота и легкость расширяемости. Линейный код без switch-ей помогает (например с табличной конфигурацией).

Возможно. В таком проекте, кстати, это имеет смысл. И то не все, а отдельные места. Но много для чего - нет.

Кстати, aviasales сейчас переписывают свои апишки с питона на go

Наверняка можно написать костыли для конкретного случая, но лучше бы иметь switch/match в языке. Мне его не хватало.

Линейный код без switch-ей помогает (например с табличной конфигурацией).

Линейный код с табличной конфигурацией уже очень далек по ясности от просто линейного кода.

unix-way I/O
ну же)

Всё на колбеках?

Нет же.

Ну или вы по «асинхроном» понимаете что-то другое

Асинхрон и понимаю.

Я же выше всё описал, сложи 2+2.

Тебе именно примеры или хватит моего ответа ниже?

unix-way I/O

И что? Речь была о линейном коде.

Я писал по-работе и на си и на си++ и на немного го, там, где это имело смысл. Те части, где это было оправдано.

разницу в производительноти от десятков до сотен и тысяч раз.

Например, когда мне надо было написать rtsp сервер, я писал его на плюсах. Сейчас, возможно, я взял бы для этого go.

Но мы про веб говорим, где ты либо ждешь ответа от внешнего апи/микросервиса, либо от бд и все упирается в них всегда или в io. Там важно сделать эффективную систему кеширования, это вопрос проектирования. А разница в производительности даже если и будет - НАМНОГО дешевле добавить железа(сменить тариф на амазоне), чем набирать новую команду и все переписывать.

Но все от задачи зависит.

Есть же нормальные языки

Как бы нету.

Асинхрон и понимаю.

Он может быть реализован сильно по разному.

Тебе именно примеры или хватит моего ответа ниже?

Я из твоего ответа таки нифига не понял.

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

Это? Если да, то, имхо, слабенько.

action = request('action')
if action == 'do1':
    ...
elif action == 'do2':
    ...
elif action == 'do3':
    ...
else:
    ...

Посмотрел гошный switch, не нашёл разницы к другим switchам, кроме того, что break писать не нужно.

И что? Речь была о линейном коде.

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

что легче человеку - следить за одной очередью или следить и держать в уме N-вариантов развития программы?

switch-case и есть goto. давайте лучше поноем что goto нет — очень уж ограничивает творческий потанцевал.

Что за мания писать на ограниченном медленном говне?

Почему бы и нет, если всю реальную работу делает СУБД?

не настолько сложнее питона

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

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

К коду, конфигурируемому таблицей, это рассуждение не относится.

14ю страницу люди обсуждают мелочи и детали яп в холиварном стиле, вместо того, чтобы писать на них код 0\ выше в треде было: зачем — чтобы писать код. Занавес же.

Работай, негр. Солнце еще высоко.

Слабенько пока значений 3. Представь 20 значений набитых в человекочитаемые констант, например (классический свитч без fallthrough):

case SOMETHING_HUMAN_READABLE_0:
case SOMETHING_HUMAN_READABLE_1:
case SOMETHING_HUMAN_READABLE_2:
case SOMETHING_HUMAN_READABLE_3:
case SOMETHING_HUMAN_READABLE_4:
case SOMETHING_HUMAN_READABLE_5:
case SOMETHING_HUMAN_READABLE_6:

Тут if value in (…) будет жестью.

У — уходи.

Чем

case SOMETHING_HUMAN_READABLE_0:
case SOMETHING_HUMAN_READABLE_1:
case SOMETHING_HUMAN_READABLE_2:

лучше, чем

if value in (
    SOMETHING_HUMAN_READABLE_0,
    SOMETHING_HUMAN_READABLE_1,
    SOMETHING_HUMAN_READABLE_2
):

Представил. Меняем case FOO на elif var == FOO, всё тоже самое.

Да, писать двадцать раз var заебёт. Но на этом всё, лапши нет, читаемость не изменяется, рефакторинг не представляет проблемы.

Не везде есть enum, для начала.

Тут if value in (…) будет жестью.

Ок, опять тебя не так понял. Думал

case SOMETHING_HUMAN_READABLE_0:
...
case SOMETHING_HUMAN_READABLE_1:
...

итд

Но почему in будет жестью?

Ну просто в класс, в tuple, неважно.

Вырвиглазно же капец, особенно если отформатировать по pep8 (не пробовал так, но должна быть жопа).

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

Вырвиглазно же капец, особенно если отформатировать по pep8

Пеп8 говорит, листы можно разбить на несколько строк, мне норм. Но аргумент годный, привыкшего к другому человека наверно будет воротить.

а я и не говорил, что так должен выглядеть роутер в web-фрэймворке

Чёт захотелось даже узнать мнение Гвидо на этот счёт, на тему того, что даже заслуженные модераторы ЛОРа уже считают себя умнее его, а он взял и сдулся в такой момент. Жаль я столько ленив и по-английски могу только объяснить оппоненту как и в каких позах мамку того я имел в виду.

request и action как-бы на это намекают.

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

Чёт захотелось даже узнать мнение Гвидо на этот счёт, на тему того, что даже заслуженные модераторы ЛОРа уже считают себя умнее его

Ты снова ничего не понял.

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

можешь подставить $filterType, $argv[0], %WHATEVER%, если такой впечатлительный

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

В Go этот быдлокод перестаёт быть былокодом, ибо запускаемая горутина, во-первых, не является потоком, а, во-вторых, на время ожидания ввода-вывода будет засыпать. В большинстве других языков тебе в этом случае нужен ивент луп, в Go он ненужен, всё асинхронно by design. Инвент луп — это планировщик, рулящий голрутинами, а ивенты — i/o и операции с каналами.

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

обычно всегда можно написать код так, что использовать их не нужно

Питонодзен, мантра номер два, explicit is better than implicit.

Ты лучше объясни почему питон должен был быть со статической типизацией? Динамическая типизация это одна из сильных сторон как по мне. Нужна будет статическая, я возьму cython, c, или вообще что-нибудь другое. Именно для ниши, которую занимает питон, динамика лучше всего. В то время из конкурентов разве что лисп был.

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

в питоне это тысячу лет назад делалось через gevent

лапшой из свитчей

Хоть switch, хоть if, хоть отдельные функции — это прекрасно структурированый код. Лапша бывает от goto. Забодали.

Такие вещи должны быть вынесены в отдельные функции/методы

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

Тем более парсинг аргументов, для этого есть готовые средства.

еще раз, речь не только про роутинг