лол ну если сырой выход двухфазного диодного моста принимать за постоянный ток, то да конечно

"Нуу...типа...от загнивающего запада!"

ну, возможно им слегка не до детального изучения мифологии

вообще говоря, преобразование фурье является весьма тяжёлым вычислительным процессом. коллега реализовывал FFT в реальном времени для аудио сигнала под android ndk и даже плюсы способны на это только при сильно ограниченном разрешении. для питона это было бы непосильно и для значительно меньших частот дискретизации, его ряд задач в плане скорости их решения в рассматриваемой области вообще очень и очень ограничен.
но в принципе я не спорю с тем, что питон сам по себе неплох для реализации взаимодействия с пользователем или прочего не требующего значительных ресурсов функционала, вполне очевидно, это так. насколько я понимаю, сам пост тоже не несёт посыла указать на несостоятельность питона как языка. просто в моём личном понимании, разделение внимания между разными языками с их разными синтаксисами и библиотеками немного, но всё же понижает эффективность разработки (особенно при встраивании одного языка в другой, как в вашем примере, или в том же ndk), при условии конечно, что оба языка предоставляют возможности к реализации заданного функционала.
вот я в своей практике в основном занимаюсь разработкой проектов под микроконтроллеры, и некоторого софта, взаимодействующего с ними. я не совсем представляю, в чём сложность использования, скажем, Qt для того же самого GUI, ведь вроде бы на нём тоже несложно построить кнопочное управление, флажки, и прочее, но добавок получается, что с и с++ используются всё время разработки, что делает процесс проще и удобнее. мне было бы интересно узнать, почему вы использовали именно такое сочетание языков, на моей практике и из того, что я видел у коллег, подобные решения обычно приводили к (скажем прямо) лёгким затруднениям в разработке и немного questionable архитектуре проекта.
несомненно тоже, что не такой большой опыт тоже может сам по себе быть затрудняющим фактором, но ведь разве аналогичный опыт, но сфокусированный на более ограниченном инструментарии, не будет давать более продуктивный результат?

Между прочим, ассемблерные вставки это порой очень полезная вещь

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

Спасибо за информацию. Ну вот например в контексте встраиваемых систем в принципе практически все задачи это задачи на обработку сигналов, так что питон в целом выглядит неэффективным в этой области

Что значит IO-емкая задача?

Я так называю переменные