Еще раз спасибо. Сел разбирать отчет. Вот результаты:
Все проблемы в _hacl уже исправлены в main (3.14.0a7+)
Убрать if (fut->fut_state != STATE_PENDING) нельзя, потому что перед второй проверкой идет потенциальный вызов Python кода PyObject_CallNoArgs(exc); – он может изменить весь C стейт
Аналогично с `start_state != deque->state` – там идет вызов `PyObject_RichCompareBool`
В целом можно заменить if (error_handler == PyERROR_UNKNOWN) на `assert(errors != PyERROR_UNKNOWN);`, но не могу назвать данное поведение ошибкой. get_error_handler_wide может начать возвращать PyERROR_UNKNOWN в любой момент
Нельзя назвать ошибкой и get_datetime_capi();, потому что сейчас там скорее хак, который не совсем корректно работает. Будет в скором временем более сложная конструкция, которая сможет вернуть NULL, но позже. Заранее иметь проверку – норм
PyXIFreeNamespace(_PyXI_namespace *ns) – можно отрефакторить, да. Но там нет ошибки, обычно PRы с просто рефакторингом - не очень охотно принимают
FStar_UInt128_u32_combine_ – не является часть CPython, а частью HACL. можно открыть багу туда. Но опять же, ошибки нет :(
`val = -1;` можно удалить, но опять же – не ошибка. Просто лишняя строка :)
py38 уже умер, минимальная версия поддержки - py39. Но вы еще почему-то устанавливаете другую версию питона для поддержки проекта тут: python = "^3.12"; так какая в итоге верная?
Указание ruff в [tool.poetry.dependencies] – плохая практика, сделайте [tool.poetry.group.dev.dependencies] для таких зависимостей
[lint] и [format] – не являются правильными ключами для настройки ruff, смотрите на [tool.ruff.lint] и [tool.ruff.format] , кажется, что вы перепутали ruff.toml и pyproject.toml
Вы почти ничего не включили: select = ["E4", "E7", "E9", "F"]
Методы вида def generate_structure(self): – не будут по дефолту проверяться mypy, потому что у них нет аннотаций (можно включить --check-untyped-defs
Нет, потому что уже большая кодовая база на С, многие авторы не знают C++. Сейчас код очень простой и понятный, введение C++ его усложнит, но не очень понимаю, какие плюсы (!) добавит.
На ютюбе такого много, например: https://www.youtube.com/watch?v=LLq7oQOIJZQ&list=PLbr8rVGhPD0WQgO97Ao67Q-QVuSbm_Zpz&index=4&t=971s А на хабре с каждым годом все меньше, потому что сложно продвигать такой контент.
Данная статья будет неполной без упоминания, что в Питоне тоже есть `Result`, `Maybe` и тд.
И типизация замечательно работает: github.com/dry-python/returns
Не нужно таким людей пугать. Тем более на собеседованиях.
Нужно использовать хороший статический анализатор, который не допустит ни одной ситуации из списка: github.com/wemake-services/wemake-python-styleguide
> У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Александр, привет! Большое спасибо за статью — прочитал с большим удовольствием. Мне особенно нравится, что ты ссылаешься на философию и выстраиваешь цепочки не от бизнеса, а от «духовности». Такой подход мне близок.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Еще раз спасибо. Сел разбирать отчет. Вот результаты:
Все проблемы в
_haclуже исправлены вmain(3.14.0a7+)Убрать
if (fut->fut_state != STATE_PENDING)нельзя, потому что перед второй проверкой идет потенциальный вызов Python кодаPyObject_CallNoArgs(exc);– он может изменить весь C стейтАналогично с `start_state != deque->state` – там идет вызов `PyObject_RichCompareBool`
В целом можно заменить
if (error_handler ==PyERROR_UNKNOWN)на `assert(errors != PyERROR_UNKNOWN);`, но не могу назвать данное поведение ошибкой.get_error_handler_wideможет начать возвращатьPyERROR_UNKNOWNв любой моментНельзя назвать ошибкой и
get_datetime_capi();, потому что сейчас там скорее хак, который не совсем корректно работает. Будет в скором временем более сложная конструкция, которая сможет вернутьNULL, но позже. Заранее иметь проверку – нормPyXIFreeNamespace(_PyXI_namespace *ns)– можно отрефакторить, да. Но там нет ошибки, обычно PRы с просто рефакторингом - не очень охотно принимаютFStar_UInt128_u32_combine_– не является часть CPython, а частью HACL. можно открыть багу туда. Но опять же, ошибки нет :(`val = -1;` можно удалить, но опять же – не ошибка. Просто лишняя строка :)
А вот
i < input_length– реальная ошибка, спасибо. Поправил https://github.com/python/cpython/issues/132769Файл pyshellext.cpp говорит, что поддерживает Vista. https://github.com/python/cpython/blob/132b6bc98f47a4d897dead8635b5a50a0baee485/PC/pyshellext.cpp#L1 Но тут я не знаю, не шарю за винду, первый раз вижу данный файл :) Можно открыть обсуждение.
В итоге – действительно проблемных кусков кода, вроде бы, к счастью не было :)
Добрый день, спасибо за анализ. Забрал в работу.
Сергей, отличные PRы, мое уважение :)
Кирилл – красавчик! Желаю успехов в карьере :)
PyList_NewиPy_BuildValueоба могут вернутьNULL. Лучше использоватьPyList_SET_ITEMвместоPyList_SetItemв данном случае.Сделал! Спасибо
Список ошибок:
`
skip-magic-trailing-comma=false`по умолчанию https://docs.astral.sh/ruff/settings/#format_skip-magic-trailing-comma не нужно указывать дефолтыВместо
excludeиспользуйтеextend-exclude, опять же: не нужно переписывать дефолты https://docs.astral.sh/ruff/settings/#extend-excludepy38уже умер, минимальная версия поддержки -py39. Но вы еще почему-то устанавливаете другую версию питона для поддержки проекта тут:python = "^3.12"; так какая в итоге верная?Указание
ruffв[tool.poetry.dependencies]– плохая практика, сделайте[tool.poetry.group.dev.dependencies]для таких зависимостей[lint]и[format]– не являются правильными ключами для настройкиruff, смотрите на[tool.ruff.lint]и[tool.ruff.format], кажется, что вы перепуталиruff.tomlиpyproject.tomlВы почти ничего не включили:
select = ["E4", "E7", "E9", "F"]Методы вида
def generate_structure(self):– не будут по дефолту проверяться mypy, потому что у них нет аннотаций (можно включить--check-untyped-defsЕсть еще множество ошибок, но мне лень разбирать дальше. В качестве вдохновения советую глянуть: https://github.com/wemake-services/wemake-python-styleguide
Добрый день! Спасибо за вопрос, очень интересно. Кажется, что нельзя; по крайней мере я сходу не могу придумать.
Нет, потому что уже большая кодовая база на С, многие авторы не знают C++. Сейчас код очень простой и понятный, введение C++ его усложнит, но не очень понимаю, какие плюсы (!) добавит.
Спасибо за развернутую обратную связь!
Ответ тянет на полноценную статью :)
Просто нужно рассказать про:
Возможность отключать
gcob_refcntв 3.13 с free-threadingИсторию вопроса
Встраиваемые версии Python
Скорость работы
На ютюбе такого много, например: https://www.youtube.com/watch?v=LLq7oQOIJZQ&list=PLbr8rVGhPD0WQgO97Ao67Q-QVuSbm_Zpz&index=4&t=971s А на хабре с каждым годом все меньше, потому что сложно продвигать такой контент.
Спасибо <3
Надо подумать, спасибо!
Плагины, которые такое проверяют:
— github.com/wemake-services/wemake-python-styleguide
— github.com/PyCQA/flake8-bugbear `B012`
И типизация замечательно работает: github.com/dry-python/returns
Нужно использовать хороший статический анализатор, который не допустит ни одной ситуации из списка: github.com/wemake-services/wemake-python-styleguide
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Но про свою компанию я рассказываю, как могу: sobolevn.me/talks/teamleadconf-2020
Полная коллекция тут: sobolevn.me
Для независимого наблюдателя есть возможность сравнить.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.