Pull to refresh
124
0
Вадим Великодный @masai

MLE

Send message

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

Нуууу… 12 комментариев (из которых треть мои :)) — это не то, чтоб супервысокий интерес.

Но книга про современный Python (вроде серии статей Hypermodern Python), наверное, многим была бы полезна.

tox и make — это всё же разные вещи, созданные с разными целями. tox (и аналогичный инструмент nox) — это автоматизация сборки и тестирования проектов на Python в разных окружениях, а make — это инструмент общего назначения для выполнения зависящих друг от друга задач.

tox не перекрывает возможности make. (Тут, конечно, можно поспорить, что такое перекрывает, так как bash-скрипты перекрывают возможности их обоих.) Более того, в документации tox об этом даже написано и предлагается использовать pyinvoke для функционала, аналогичного make. Собственно, tox не то, чтоб очень универсален, иначе бы не появился nox.

Это не значит, что tox — плохой инструмент. Отличный! (Хотя я в какой-то момент перешёл на nox, а потом и на возможности Hatch по созданию матрицы версий.) И действительно, он позволяет делать в пару строк то, что с помощью make сделать сложно.

Просто глаз зацепился за сравнение инструментов из разных категорий.

Тут не совсем корректно говорить об отличии. Poetry просто следует этому стандарту.

PEP 518 очень простой. Он лишь задаёт список зависимостей для системы сборки (обычно там одна зависимость — сама система) и указывает, что все свои настройки система должна хранить в tool.ИМЯ. В случае Poetry это tool.poetry.

Технически никто не мешает использовать одновременно две системы сборки (например, Poetry и Flit) используя один и тот же project.py. Правда смысла в этом не очень много. Разве что на время переходного периода.

Ну и инструменты вроде black, bandit, pytest могут хоанить свои настройки там же.

А вот в чём Poetry стандартам не следует, так это в PEP 621. Этот стандарт говорит, что все метаданные должны храниться в таблице project включая зависимости. Poetry же для зависимостей использует собственную таблицу tool.poetry.dependencies. Более того, он использует нестандартный спецификатор версий (символ ^), не предусмотренный PEP 508.

В Poetry 2.0 скорее всего появится поддержка PEP 621, но ценой отказа от нестандартных элементов.

Наиболее полно стандарты сейчас поддерживает разве что Hatch (что неудивительно, так как он теперь проект PyPA). Но это не значит, конечно, что нужно немедленно на него переходить. Всё зависит от проекта и того, что именно нужно для его разработки и сборки.

У нас на кафедре был переносной экран. В целом, жить можно, но да, таскать неприятно.

Насчёт Taskfile согласен, но даже в нынешнем виде он поприятнее Makefile. Я часто писал мейкфайлы, и после них Taskfile — глоток свежего воздуха.

А Hatch с недавних пор под крылом PyPA. Развивается тоже очень активно несмотря на то, что появился меньше года назад. Poetry уже 4 года, и он тоже на первых порах разрабатывался парой этузиастов.

У Poetry довольно много неочевидных проблем. Например, работа с приватными репозиториями — это боль, так как Poetry не использует pip. А у нас на работе настроена ротация ключей и поддержки чего-то кроме pip ждать не приходится. В итоге пришлось писать свой плагин. Альтернатива — дампить requirements.txt и ставить из него. Ситуация ещё усложнялась тем, что в CI/CD доступ к репозиторию был через прокси, то есть URL другой. И lock-файлы превращались в тыкву, так как нет простого способа подменить адреса.

Были проблемы с установкой пакетов из дополнительных индексов, когда резолвер качал даже версию под Windows работая на Linux. Ну и много других неприятных мелочей.

Справедливости ради, в Hatch вообще нет lock-файлов пока их поддержка не появится в pip. Но он внутри использует pip, то есть более практичен.

И у Poetry, и у Hatch проблемы со сборкой бинарных пакетов. У первого есть build.py, но это нестабильная фича, у второго пока нет внятного решения. Но с другой стороны, свет на них клином не сошёлся. В таких случаях я просто пишу setup.py.

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

Хотя для пет проекта, где можно переписать весь ci/cd за вечер на чем угодно, наверное, забавно.

Вряд ли эта статья ориентирована на людей, которые делают сложный CI/CD в большом проекте. :) Так-то у нас на работе одна команда вообще Bazel для питона использует.

Маркерные доски блестящие, они отражают, а не рассеивают, поэтому картинка на них получается плохая. Лучше на белую стену наводить (при наличии).

Вместо setup.py я бы посоветовал использовать Poetry или Hatch. (Я долгое время пользовался Poetry, но в последнее время больше склоняюсь к Hatch.) Это, кстати, заодно решило бы проблему установки зависимостей, нужных для разработки, и позволило бы избавиться от pipenv (а в случае Hatch, и от Tox).

А вместо Makefile удобно пользоваться Taskfile.

Для тех, кому интересен современный Python, есть неплохая серия статей Hypermodern Python.

Раскройте более подробно Вашу мысль "Их используют, когда объект
предназначен для хранения значений, к которым осуществляется доступ
через точку, а в примерах полноценные классы с методами ".

Вот цитата из PEP 557, посвящённого датаклассам:

Although they use a very different mechanism, Data Classes
can be thought of as “mutable namedtuples with defaults”.

Уже из этого предложения (хотя там довольно много объяснений и кроме него) видно, что датаклассы изначально задумывались как абстракция кортежа, кусочка данных. Иными словами, они больше дата, чем классы. Все методы, которые добавляет декоратор, так или иначе предназначены для работы с полями.

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

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

А вот если у нас есть класс для принтера, то это уже не данные. Это некоторая абстракция, с которой мы будем взаимодействовать с помощью методов. То есть, принтер — это не запись с именованными полями. Да, внутри, конечно, какие-то атрибуты есть, но они должны быть скрыты. Да и к чему классу принтера методы для работы с полями, которые добавит декоратор?

Было интересно услышать доводы того, кто поставил минус.

То есть, проблема именно в Поттере, а не в низкой квалификации?

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

Ещё можно понять, почему Rectangle — датакласс (хотя это тоже спорный вопрос), но Printer у меня совсем не ассоциируется с данными.

Однако даже в Rectangle и Square датаклассы используются очень необычным образом. Поля объявлены как private, а потом отдельно объявлены одноимённые свойства. Но зачем датакласс тогда нужен, если ни одно из преимуществ датаклассов не используется?

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

Сравнение, которое всегда выдаёт результат за одно и то же время.

Explained using Python в оригинальном заголовке — это причастие, то есть дословно означает объяснённая с помощью Python. Страдательный залог в прошедшем времени тут никак не получить.

Ложная дихотомия. Никто не утверждает ничего подобного. Гарантий нет, но меньше риск допустить ошибку.

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

В функциональных языках неизменяемость очень распространена, поэтому можно, например, посмотреть книжку Криса Окасаки о чисто функциональных структурах данных.

Я именно американский и смотрю. $300-500k — это не зарплата, а total compensation, то есть вместе с акциями. Заплата меньше. Это не то же самое, в чём, например, имели несчастье убедиться сотрудники некоторых букв FAANG (вернее, уже MANGA), у которых резко упали цены на акции.

Перед аббревиатурами тоже ставится артикль, если он есть в полной форме. The USA, the UK или the BBC. Но в том-то и дело, что в on television артикля почему-то нет.

Да нормальная зарплата. Хотя на личную яхту может и не хватить, конечно.

Information

Rating
Does not participate
Location
London, England - London, Великобритания
Registered
Activity