Обе структуры имеют больше методов чем нужно для стека. То есть нет идеального совпадения по API. Очевидного кандидата я не вижу.
Алгоритмический стек часто реалтзуют через Array. ArrayList внутренне устроих очень близко к Array.
По производительности логика такая, что в ArrayList удаление последнего элемента будет очень быстрым так как это замена одного элемента в памяти. Вставка в основном такая же, но иногда надо сделать ресайз. Это настолько частые операции, что они оптимизированны на разных уровнях, в том числе и на железе.
Что внутри ArrayDeque нагуглить с наскока не удалось, но там явно есть двунаправленные ссылочки. А значит их надо добавлять, удалять. Работа не с единым кусом пямяти, а с разными это уже будет медленее. Хотя в рамках этой задачи она может быть и ниже погрешности измерений.
Ну и косвенные наблюдения, если бы ArrayDeck был быстрее Array на стековых задачах, то его бы чаще использовали. А так я редко вижу его вне алгоритмических задач.
Преждевременной оптимизацией это будет, если вы меня убедите, что код с использованием ArrayList будет сложнее.
Котлин совместим с Джава, можно даже при желании писать половину файлов на одном, половину на другом языке в рамках одного проекта. Так что вполне универсальный.
Мне нравится, что убрали много кривого АПИ которое в джаве существует только по причине обратной совместимости, ну и более строгие типы: нативная поддержка nullable и не nullable объектов.
Синтаксис очень сахарный с закосом под функциональные языки. Мне лично нравится. Идиоматичный Котлин мне кажется посложнее Джавы.
За основу я взял примеры описаний из гибких методологий и разделил их по типам:
Для начала можно и тремя обойтись. Просто чтобы не перегружать людей. А остальные добавлять по мере необходимости.
Epic (Большая задача)
Feature (Новая функциональность)
Bug (Исправление ошибок)
Шаблоны описания
Лучше, когда это формы в багтрекере. Например https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
Ну и конечно автоматизация и еще раз автоматизация. Закрывать тикеты автоматом комментарием в коммите - это очень удобно (https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). Гитхуки для проверки наличия тикета в коммите помогают не забыть про него. (можно настроить через https://jorisroovers.com/gitlint/latest/).
У меня скриптик скачивает джейсоны и потом их процессит, diskcashe для этого удобнее, так как не надо менять формат данных. А sqlite там внутри работает.
В обезьяней стае есть самцы. Качестава которые во описали им неообходимы. От мужчины ожидается намного больше чем от самца. Как минимум соответсвующего поведения в обществе.
Переход на личности и бросание фекалий в опонентов это больше про отсутствие культуры, а не про сильную личность.
Во всех айти компаниях, где я работал, такое поведение считалось токсичным.
Для меня такой стиль общения, это огромный красный флаг для кандидата.
Я бы не рекомендовал использовать многопоточность самостоятельно для веба, там могут быть свои заморочки. И GIL не худшая из них. Это такие вещи, где действительно нужны серьёзные знания. Есть гораздо более надёжные и простые решения. Например:
В проекте я использую Celery
Это правильный подход. И еще он избавляет вас от необходимости понимания GIL.
Да пусть даже языка. Оптимизировали очень маленькую часть веб сервиса. А в остальных местах может даже и выиграли по времени. Надо считать общий резальтат, а не яркие места.
Хотя мне опыт работы с SpringBoot на джаве и котлине понравился. Например, Метрики и трейсинг подключаются через пару строк в кофиге и дают вполне годный результат.
Так это именно то о чем я и говорил. Вы не отправляете письмо когда выходите из send_email. Оно потом когда-нибудь отправится и может потеряться при перезапуске сервера.
Обе структуры имеют больше методов чем нужно для стека. То есть нет идеального совпадения по API. Очевидного кандидата я не вижу.
Алгоритмический стек часто реалтзуют через Array. ArrayList внутренне устроих очень близко к Array.
По производительности логика такая, что в ArrayList удаление последнего элемента будет очень быстрым так как это замена одного элемента в памяти. Вставка в основном такая же, но иногда надо сделать ресайз. Это настолько частые операции, что они оптимизированны на разных уровнях, в том числе и на железе.
Что внутри ArrayDeque нагуглить с наскока не удалось, но там явно есть двунаправленные ссылочки. А значит их надо добавлять, удалять. Работа не с единым кусом пямяти, а с разными это уже будет медленее. Хотя в рамках этой задачи она может быть и ниже погрешности измерений.
Ну и косвенные наблюдения, если бы ArrayDeck был быстрее Array на стековых задачах, то его бы чаще использовали. А так я редко вижу его вне алгоритмических задач.
Преждевременной оптимизацией это будет, если вы меня убедите, что код с использованием ArrayList будет сложнее.
Котлин совместим с Джава, можно даже при желании писать половину файлов на одном, половину на другом языке в рамках одного проекта. Так что вполне универсальный.
Мне нравится, что убрали много кривого АПИ которое в джаве существует только по причине обратной совместимости, ну и более строгие типы: нативная поддержка nullable и не nullable объектов.
Синтаксис очень сахарный с закосом под функциональные языки. Мне лично нравится. Идиоматичный Котлин мне кажется посложнее Джавы.
Поискал в доках и нечего не нашёл, что именно этот event значит. Видимо да никакого события на апруве не выкидывается.
Мои настройки линтеров будет ругаться на такое имя. https://docs.astral.sh/ruff/rules/error-suffix-on-exception-name/
И я стараюсь избегать Not в именах.
Может быть: ConstantChangeError
Напоминает работу с бэкэндом. Вы обслуживает много паралельных запростов, но зачастую в коде многопоточность вообще не используете.
Потому, что ArrayList для этой задачи достаточно, он быстрее и лучше по памяти. Это только алгоритмические параметру у них одинаковые.
Для начала можно и тремя обойтись. Просто чтобы не перегружать людей. А остальные добавлять по мере необходимости.
Epic (Большая задача)
Feature (Новая функциональность)
Bug (Исправление ошибок)
Лучше, когда это формы в багтрекере. Например https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
Ну и конечно автоматизация и еще раз автоматизация. Закрывать тикеты автоматом комментарием в коммите - это очень удобно (https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests#linking-a-pull-request-to-an-issue). Гитхуки для проверки наличия тикета в коммите помогают не забыть про него. (можно настроить через https://jorisroovers.com/gitlint/latest/).
Не на pypi и то хорошо.
Нормальный учебный проект, автор научится чему-то новому.
У меня скриптик скачивает джейсоны и потом их процессит, diskcashe для этого удобнее, так как не надо менять формат данных. А sqlite там внутри работает.
В статье нет сравнения с аналогами. А их много. Например diskcache.
SQL тоже может быть лёгким, например sqlite.
Не плохо бы замутить какое-нибудь сравнение по производительности.
HTTPX подходит и для синхронных.
Если рассматривать структуры данных в плане алгоритмов, то неплохо бы еще и добавить что-то про сложность.
Мне очень нравится формат использующийся в этом документе для Python.
https://wiki.python.org/moin/TimeComplexity
ArrayList реализует структуру на которой можно сделать стек (структуру данных)
В обезьяней стае есть самцы. Качестава которые во описали им неообходимы. От мужчины ожидается намного больше чем от самца. Как минимум соответсвующего поведения в обществе.
Переход на личности и бросание фекалий в опонентов это больше про отсутствие культуры, а не про сильную личность.
Во всех айти компаниях, где я работал, такое поведение считалось токсичным.
Для меня такой стиль общения, это огромный красный флаг для кандидата.
А про остальных людей кому приходят уведомление о новых комментариях вы подумали?
Я бы не рекомендовал использовать многопоточность самостоятельно для веба, там могут быть свои заморочки. И GIL не худшая из них. Это такие вещи, где действительно нужны серьёзные знания. Есть гораздо более надёжные и простые решения. Например:
Это правильный подход. И еще он избавляет вас от необходимости понимания GIL.
Языка или алгоритмов.
Да пусть даже языка. Оптимизировали очень маленькую часть веб сервиса. А в остальных местах может даже и выиграли по времени. Надо считать общий резальтат, а не яркие места.
Хотя мне опыт работы с SpringBoot на джаве и котлине понравился. Например, Метрики и трейсинг подключаются через пару строк в кофиге и дают вполне годный результат.
Так это именно то о чем я и говорил. Вы не отправляете письмо когда выходите из
send_email. Оно потом когда-нибудь отправится и может потеряться при перезапуске сервера.Чудеса. В главном потоке долго а в другом быстро. Мгновенно будет, если не ждать завершения второго потока и отвечать пользователю сразу.
А какой объём данных?
При мягкой перезагрузке сервера данные успевают отправится?
Если процесс убьют, то получается пользователь получит ответ, а данные в кавку не уйдут.