aiogram тянет aiohttp, там отличный http клиент, получается что httpx лишняя зависимость, так же раньше aiohttp уделывал его по скорости, но как с этим сейчас, не знаю, возможно уже доработали
Капитанство какое-то. Ну и везде одни "Преимущества", а как насчет недостатков? Например, set теряет порядок, сложные comprehensions не улучшат читаемость, а сделают наоборот.
именно устанавливает, правда не знаю как именно устанавливает conda, но будет именно версия которой нет в системе, а, ну и установка конечно же будет не системная, что правильно, системный python лучше ставить только пакетными менеджерами системы
скорость очень значимый параметр, еще удобная установка версий python, uv по нормальному агрегировал кучу фич разбросанных по разным инструментам, плюс свои фишки
чтобы использовать конкретное виртуальное окружение, если напрягает, то можно активировать через source или другими способами, тогда будет работать python hello.py
и вот прям сразу спорный момент, по мне, coord и new_x_coord тут избыточно, название класса и последующий контекст достаточен чтобы были короткие имена x и y, так же спорно название метода change_coordinates, но мне сложно сейчас предложить вариант, тут я бы отталкивался от общей роли этого класса в проекте. Итог:
class GeometricFigure:
def __init__(self, name: str, x: int, y: int):
self.name = name
self.x = x
self.y = y
def change_coordinates(self, x: int, y: int):
self.x = x
self.y = y
а еще, когда вдруг у фигуры, сначала идет какое-то name, а не логичные x и y, я хочу именованные аргументы
Основные затраты времени, это обдумывание решений и тому подобное. Код относительно этого пишется быстро, а всякие автодополнения, алиасы и прочее, больше субъективные удобства, их влияние на общее время разработки незначительное. Так что "сэкономленные" это больше манипуляция статистикой.
Основной смысл параметра заключается в том, чтобы при использовании критических функций, таких как удаление таблицы или всех данных из таблицы, необходимо было явно указывать тот пароль, который был передан при инициации класса. Это сделано для защиты от случайного удаления данных и от несанкционированного доступа.
Тащить метод из интерактивного взаимодействия в сам код, очень сомнительное решение, откуда взялось случайно удаление в самом коде? Да и несанкционированный доступ, тут тоже боком.
Сейчас малоизвестные - Litestar, PonyOrm, Rye, а мерятся звездами вообще последнее дело. Болото у всех свое, но я точно могу сказать, что про FastAPI больше знают, чем даже про упомянутый Sanic, про Litestar уже молчу.
А с unitest всё не так, как и с threading, им не очень удобно пользоваться, обычно проще concurrent.
Потому что половина из этого очень малоизвестные библиотеки, еще странно сравнивать стандартный unittest с pytest, а про установку пакетов, я сразу написал, что есть варианты, вот почему вы conda захотели, а не, например uv (почему вообще сравнение Poetr с Rye и Pipenv с conda, это отдельные пункты)? так же с другими, flake8 как пример, вот я же упомянул тот же ruff, он сейчас уже может заменить кучу из подобных.
А про "лютые костыли", так это часто проблема не библиотеки, а именно конкретного приложения.
Возьмем Litestar, я про него только сейчас узнал, зачем сейчас мне тащить его в свой стек разработки? С тем же FastAPI такой вопрос был года два назад (а может и раньше, точно не скажу), но он доказал свою эффективность. Возможно с Litestar так же будет, а может и нет.
aiogram тянет aiohttp, там отличный http клиент, получается что httpx лишняя зависимость, так же раньше aiohttp уделывал его по скорости, но как с этим сейчас, не знаю, возможно уже доработали
Капитанство какое-то. Ну и везде одни "Преимущества", а как насчет недостатков? Например, set теряет порядок, сложные comprehensions не улучшат читаемость, а сделают наоборот.
именно устанавливает, правда не знаю как именно устанавливает conda, но будет именно версия которой нет в системе, а, ну и установка конечно же будет не системная, что правильно, системный python лучше ставить только пакетными менеджерами системы
кому что удобно, тот то и использует, вообще не вижу тут проблемы
скорость очень значимый параметр, еще удобная установка версий python, uv по нормальному агрегировал кучу фич разбросанных по разным инструментам, плюс свои фишки
чтобы использовать конкретное виртуальное окружение, если напрягает, то можно активировать через source или другими способами, тогда будет работать python hello.py
и как этот ответ связан с моим вопросом?
и какой смысл нагонять сюда подобных комментаторов? никакой пользы от них нет, да еще и выглядят как боты
Стоило упомянуть альтернативы внутри того же Redis: простейшее - собрать подобное на lists и более навороченный - Redis Streams
а почему не сразу так?
и вот прям сразу спорный момент, по мне, coord и new_x_coord тут избыточно, название класса и последующий контекст достаточен чтобы были короткие имена x и y, так же спорно название метода change_coordinates, но мне сложно сейчас предложить вариант, тут я бы отталкивался от общей роли этого класса в проекте. Итог:
а еще, когда вдруг у фигуры, сначала идет какое-то name, а не логичные x и y, я хочу именованные аргументы
ага, а если учесть что у aiogram под капотом aiohttp, то можно сказать, что асинхронный клиент уже досутпен из коробки.
Основные затраты времени, это обдумывание решений и тому подобное. Код относительно этого пишется быстро, а всякие автодополнения, алиасы и прочее, больше субъективные удобства, их влияние на общее время разработки незначительное. Так что "сэкономленные" это больше манипуляция статистикой.
Тащить метод из интерактивного взаимодействия в сам код, очень сомнительное решение, откуда взялось случайно удаление в самом коде? Да и несанкционированный доступ, тут тоже боком.
оставлю ссылку на интересную статью про декораторы https://habr.com/ru/articles/750312/ чтобы было с чем сравнивать
Ваш пример для ЯП со слабой типизацией, у python она строгая, а тут подняли проблему динамической типизации, это как бы совсем другое.
вы упорно приводите примеры проблемы, которой нет в Python, вам упорно говорят, что тут подняли немного другую проблему
потому что, зачем нам писать свою обертку для Starlette, когда уже есть FastAPI
Сейчас малоизвестные - Litestar, PonyOrm, Rye, а мерятся звездами вообще последнее дело. Болото у всех свое, но я точно могу сказать, что про FastAPI больше знают, чем даже про упомянутый Sanic, про Litestar уже молчу.
А с unitest всё не так, как и с threading, им не очень удобно пользоваться, обычно проще concurrent.
Потому что половина из этого очень малоизвестные библиотеки, еще странно сравнивать стандартный unittest с pytest, а про установку пакетов, я сразу написал, что есть варианты, вот почему вы conda захотели, а не, например uv (почему вообще сравнение Poetr с Rye и Pipenv с conda, это отдельные пункты)? так же с другими, flake8 как пример, вот я же упомянул тот же ruff, он сейчас уже может заменить кучу из подобных.
А про "лютые костыли", так это часто проблема не библиотеки, а именно конкретного приложения.
Возьмем Litestar, я про него только сейчас узнал, зачем сейчас мне тащить его в свой стек разработки? С тем же FastAPI такой вопрос был года два назад (а может и раньше, точно не скажу), но он доказал свою эффективность. Возможно с Litestar так же будет, а может и нет.