Единственный минус такого подхода заключается в том, что, без дополнительных усилий, не получится воспользоваться в своём коде командой вида import module_a. Для этого потребуется кое-что сделать. <…>

Проблема хорошо решается вызовом pip install -e . в окружении, в котором вы работаете (pyenv/conda/etc). В этом случае можно просто импортировать тестируемый пакет в тесты.

Не совсем понял, зачем внутри src находятся тесты. Они сами по себе не то чтобы являются исходным кодом пакета. Плюс, если использовать пример setup.py из https://github.com/pypa/sampleproject, где есть строчка packages=find_packages(where="src"), то при упаковке пакета папка test попадёт внутрь. Нужна ли она пользователю пакета? Мне так не кажется. Хотя при более тонкой настройке packages, естественно, она в пакет не попадёт.

В остальном приличный гайд. Советы полезные.

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

> Декоратор – не что иное, как функция

это неверное утверждение

Почему? В словаре питона написано буквально "A function returning another function, usually applied as a function transformation using the @wrapper syntax".

Но всё-таки Box мне всё ещё кажется не подходящим названием, хоть и общеиспользуемым.

Что угодно становится проще, если на это писать, конечно же. Просто таких ощущений у меня не возникает, когда читаешь код на javascript, С#, Ada, PHP, Java и даже Tcl. А тут возникают.

А ещё больше отталкивает наличие большого количество "слов" в коде программы, несущих чисто "служебное" значение и не имеющих прямое отношение к логике программы. Например, "unwrap" и его вариации, встречающиеся постоянно, "cloned", "get_mut", "boxed".

Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.

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

Помимо libc и самого языка Си в проекте могут использоваться библиотеки. Например, RTOS, FS и пр. Каким образом они подключаются и компилируются в C? Да как придётся. Хорошо, если есть CMake или Make в репозитории. Иначе бери, копируй файлы, компилируй всё сам. Так что непонятно что вас смутило в системе, которая значительно упрощает управление зависимостями проекта.

А потом вышла Stm32CubeIDE и сломала совместимость с CMake плагинами. Хочется работать — генерируюй проект в CubeMX. А когда у тебя CI и всё проекты на CMake + в основном ты пользуешься libopencm3… Пришлось оставить надежду и уйти на VS Code. Очень жаль, что так вышло.

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