[
query_param.split('=')[1]
for query_param in url.split('?')[1].split('&')[-3:]
]
Что я по факту сделал:
Вспомнил, что пишу на Python, а в Python map не юзают, а lambda вообще стараются не использовать, у каждого языка есть свои принятые способы реализации того или иного кода. Вместо map в Python юзают list comprehension
Вспомнил, что дядюшка Боб (Чистый код. Роберт Мартин) завещал отрубать руки поправлять тех кто использует однобуквенные переменные.
Заюзал Black форматирование. Кстати, поначалу я вообще не понял в чём прикол, вроде же Python про компактность кода, а тут предлагается все разворачивать и код пухнет как на дрожжах, но потом свыкся и даже отчасти проникся.
Что ещё можно сделать, если это код не урлы, которые мы все и так понимаем:
Заюзать namedtuple, в него скидывать результат сплита, а дальше уже юзать удобный объект.
Вынести в константы с понятным названием строковые литералы.
Что здесь всё равно остается вообще не понятным: почему мы берём только 3 последних query параметра?
Python - лучший второй язык. На нём можно сделать всё что угодно, а потом, при достижении потолка производительности, всё или отдельные части переписать на нишевый язык.
Дело в том, что далеко не каждая компания может достичь потолка производительности Python.
Зато порог вхождения в Python минимален, а основной упор языка делается на читабельность. Ну а так как 80% времени мы код читаем и лишь 20% времени пишем, то Python позволяет быстрее фичи пилить, поддерживая архитектуру приложения в должном виде, ну т. е. меньше техдолга получается относительно других языков (я пишу также на TypeScript и С (микроконтроллеры), чуточку Golang, раньше писал на C++, C#, HaXe и Perl)
Например, Python очень хорош для написания бэкенда web-приложений. FastAPI и Robyn дают возможность вывозить более-менее значимые нагрузки, понятно, что полноценный highload лучше на нишевом языке (Go или Rust).
Исключением является только, наверно, мобильные приложения и фронтенд, их, конечно, то же можно на Python писать, но переписывать слишком много придется и архитектуру выстраивать полностью с нуля. Только если бизнес-домен сформировать, да проверить UX на пользователях. Но этот UX будет такой медленный, что может сложиться не корректное впечатление об его удобстве/неудобстве.
Даже в умном доме можно использовать Python при проектировании. Использовать какой-ньть Onion сначала, а по завершению апробации, заменить уже на ESP'шки какие-ньть с кодом на C.
Думаю, когда это произойдет, для меня выбор будет очевидным.
ИМХО, не скоро ещё async ORM Django станет юзабельным. Сначала будет исправление тонны багов, потом оптимизация, ну и синтаксис, конечно, придумали убогий.
Надо было при переходе на 4ю мажорную версию, когда была возможность сделать именно мажорные (обратно не совместимые) изменения переделывать ORM, а теперь они связаны обратной совместимостью, так что весь async будет завозиться на "кастылях", так что по нормальному async ORM запилят только в версии 5 Django.
Очень любил Django, до того как в Python завезли async, почему-то maintainer'ы Django прое... момент, когда надо было бросать всё и завозить async в Django. Да я знаю, что async на уровне обработчиков появился в 3-й версии Django, но без async ORM, он нахер не нужен. Исключения, это проксирование запросов и когда можно достать данные из кеша и не ходить в БД, но очень маленький процент приложений.
Пока очевидный выбор это TortoiseORM, если хочется синтаксис Django и хочется быть быстрее SQLAlchemy (правда, не всегда).
А почему не упомянули про фабрику жадных корутин?
Там обещают прирост производительности до 50%
https://docs.python.org/3.12/library/asyncio-task.html#asyncio.eager_task_factory
https://github.com/python/cpython/issues/104144
Интересно было бы послушать мнение ведущих подкаста о фреймворке Robyn (под капотом Rust). Он также является и HTTP-сервером (а-ля guvicorn/uvicorn).
Интересно, что можно выжать из Python в рамках этой же задачи.
Надо будет попробовать заюзать Cython + Pandas и посмотреть во что выльется по скорости.
Хмм... вот исходная строка:
А вот как я бы её на Python зарефачил:
Что я по факту сделал:
Вспомнил, что пишу на Python, а в Python
mapне юзают, аlambdaвообще стараются не использовать, у каждого языка есть свои принятые способы реализации того или иного кода. Вместоmapв Python юзают list comprehensionВспомнил, что дядюшка Боб (Чистый код. Роберт Мартин) завещал
отрубать рукипоправлять тех кто использует однобуквенные переменные.Заюзал Black форматирование. Кстати, поначалу я вообще не понял в чём прикол, вроде же Python про компактность кода, а тут предлагается все разворачивать и код пухнет как на дрожжах, но потом свыкся и даже отчасти проникся.
Что ещё можно сделать, если это код не урлы, которые мы все и так понимаем:
Заюзать namedtuple, в него скидывать результат сплита, а дальше уже юзать удобный объект.
Вынести в константы с понятным названием строковые литералы.
Что здесь всё равно остается вообще не понятным: почему мы берём только 3 последних query параметра?
Python - лучший второй язык. На нём можно сделать всё что угодно, а потом, при достижении потолка производительности, всё или отдельные части переписать на нишевый язык.
Дело в том, что далеко не каждая компания может достичь потолка производительности Python.
Зато порог вхождения в Python минимален, а основной упор языка делается на читабельность. Ну а так как 80% времени мы код читаем и лишь 20% времени пишем, то Python позволяет быстрее фичи пилить, поддерживая архитектуру приложения в должном виде, ну т. е. меньше техдолга получается относительно других языков (я пишу также на TypeScript и С (микроконтроллеры), чуточку Golang, раньше писал на C++, C#, HaXe и Perl)
Например, Python очень хорош для написания бэкенда web-приложений. FastAPI и Robyn дают возможность вывозить более-менее значимые нагрузки, понятно, что полноценный highload лучше на нишевом языке (Go или Rust).
Исключением является только, наверно, мобильные приложения и фронтенд, их, конечно, то же можно на Python писать, но переписывать слишком много придется и архитектуру выстраивать полностью с нуля. Только если бизнес-домен сформировать, да проверить UX на пользователях. Но этот UX будет такой медленный, что может сложиться не корректное впечатление об его удобстве/неудобстве.
Даже в умном доме можно использовать Python при проектировании. Использовать какой-ньть Onion сначала, а по завершению апробации, заменить уже на ESP'шки какие-ньть с кодом на C.
ИМХО, не скоро ещё async ORM Django станет юзабельным. Сначала будет исправление тонны багов, потом оптимизация, ну и синтаксис, конечно, придумали убогий.
Надо было при переходе на 4ю мажорную версию, когда была возможность сделать именно мажорные (обратно не совместимые) изменения переделывать ORM, а теперь они связаны обратной совместимостью, так что весь async будет завозиться на "кастылях", так что по нормальному async ORM запилят только в версии 5 Django.
Очень любил Django, до того как в Python завезли async, почему-то maintainer'ы Django прое... момент, когда надо было бросать всё и завозить async в Django. Да я знаю, что async на уровне обработчиков появился в 3-й версии Django, но без async ORM, он нахер не нужен. Исключения, это проксирование запросов и когда можно достать данные из кеша и не ходить в БД, но очень маленький процент приложений.
Пока очевидный выбор это TortoiseORM, если хочется синтаксис Django и хочется быть быстрее SQLAlchemy (правда, не всегда).