Прошу рассказать о каких-либо примерах применения Python в Embedded.

Все чаще в вакансиях встречаю требование знать Python. Ума не приложу где его можно применить программисту C++.

Поделитесь опытом, как Python и скрипты сделали вашу жизнь проще. Возможно, в тестировании как-то это полезно?...

Использую как вспомогательный инструмент для преобразования массивов данных там, где не хватает скилов применить Excel

например pyserial - какой-нибудь лабудой по UART (через USB2UART) управлять
обработка текстовых файлов - например из нетлиста схемы сгенерить констрейны для ПЛИС (раньше использовал awk, но python гораздо удобнее)
также всякая "внезапная" деятельность - например, понадобилось s-record распечатать в hexdump - pip instal bincopy и готово , а на С++ это писать - день возни
раньше под винду использовал pywin32 для всякого "автомейшина" - то есть из PADSa какие-то данные доставал, в эксель вставлял - наверно это и бейсиком можно, но я бейсика не знаю, и когда на нем пытался что-то делать испытывал только отрицательные эмоции, а питон очень удобен

Тесты, кодогенераторы (когда нужно сделать узкозаточенное железо, с кучей одинаковых блоков с разными коэффициентами), модели, для проверки концепции, кроме того, визуализация достаточно легко делается (графики, гистограммы, созвездия)

Питон встроен в свежий KiCAD, LibreOffice и т.п. - можно автоматизировать некоторые вещи.

Помимо автоматизации рутинных операций Python очень крут для анализа данных, моделирования и исследований - библиотеки numpy, matplotlib, jupyter и т.д (на венде лучше всего установить пакет Anaconda). Например, jupyter notebook - веб приложение класса computational notebook, позволяющее эффективно вести исследования и расчёты, совмещая с документированием. Вот я ради пробы побаловался.

Тут в ячейке 1 цепляемся к процессу, который гонит видеопоток, во 2-й ячейке выдёргиваем кадр (объект f), в 3-й выводим кадр, в 4-й выводим профиль 60-й строки. Далее можно делать что угодно - строить и анализировать гистограммы, наводить статистику, производить обработку изображения. Кадров можно выдрать сколько угодно и работать с их массивом.

Вот тут более взрослое использование фич jupyter notebook - прямо законченный документ, с оформлением, данными, вычислениями, ссылками и т.д. Помимо показанного там ещё можно писать формулы в формате LaTeX, получается очень красиво. Здесь обзор некоторых фич.

Кроме того, очень удобно писать вспомогательный и/или технологический софт, в том числе когда требуется GUI - например, с использованием биндинга PyQt. Скорость разработки возрастает по сравнению с кодированием на С++, а скорость приложения получается почти такой же. Критичные места можно реализовать на С++. Одной из самых крутых фишек является возможность внедрить в приложение на PyQt ядро jupyter и получить доступ к потрохам приложения в питоновой консоли по типу IPython со всеми плюшками в виде автодополнения, умной истории команд, возможности использовать всю мощь matplotlib и т.д. Доступ по чтению и записи - т.е. можно оперативно выхватывать данные из приложения и изменять внутренние объекты интерактивно. Нам очень это помогает при работе с видеопотоками от камер.

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

Этот дебильный пхытон куда только нынче не пихают!
Но на мой взгляд изучать его нет необходимости, особенно в embedded, где кроме С и ассемблера ничего не нужно.
А во всяких embedded-linux'ах тоже пхытону места нет: скрипты на bash или zsh значительно удобней. И читаются намного легче идиотского синтаксиса пхытона.

расскажите об этом любителям ардуино)

Нет, как раз ПО будет неэффективным. Но это прямо провозглашено в идеологии питона - он не для производительности ПО, он для производительности труда. Поэтому, правильнее будет не "построения эффективного ПО...", а "эффективного построения ПО".

Кстати, рекомендую сразу правильно пользоваться операторами сложения, конкатенации и т.п. Потому что это сейчас питон - язык с динамической типизацией, но постепенно такие языки приходят к строгой типизации, и этот путь уже прошли perl и php. В этом плане тоже идеология питона мне приятна - "должен быть только один способ сделать что-либо правильно".

Наверное спорно- случаи есть разные: мне кажется в озвученном контексте проще в качестве примера привести какой-нибудь Rust , который вроде как очень неплох и интересен на бумаге, но что-то не видно "серьезного" софта(HPC, эмбед без мейкерских иот/бле игрушек и пр). Или я отстал от жизни?

Наверняка есть разные случаи, и, действительно, есть всегда есть смысл обговорить точку отсчёта. Но, как правило, код на C - это 10% аппаратных затрат того же алгоритма, но выполненного на perl/python. В perl эту задачу решили, сделав математические и dsp-шные библиотеки на C, и прикрутив к ним perl'овский интрефейс, то есть, для программиста на perl это выглядит как обыкновенный perl'овый модуль. Но там хитрость - передача данных от perl к C и обратно требует накладных расходов, поэтому, даже если делать всё правильно - собирать большие объёмы данных и уже их отправлять на обработку в модуль, то можно достичь производительности 90% от кода на чистом C. На python мне такое делать не приходилось, но уверен на 140%, что там есть что-то похожее, правда, оставляю 6%, что подобного там нет. В то время, когда я подобными вещами пользовался, ещё не было. Но, признаюсь, синтаксис perl мне нравится больше, чем python, считаю python хипстерским языком, что, однако, не мешает мне видеть его сильные стороны (ну или я на это надеюсь).

Хорошее сравнение: как абдуринщики лепят свои поделки, совершенно не вникая суть и по принципу "абы работало" ("а если не хватит этой абдурины, возьмем более мощную или 2-3-5 штук") вместо того, чтобы взять нормальный микроконтроллер и почитать даташит, так и пхытон раскручивают, чтобы люди, вообще не имеющие даже базовых основ программирования, могли надергать куски готового кода и слепить "абы работало". А то, что оно тормозит как не в себя и ресурсов жрет неплохо, их не пугает: ведь можно проапгрейдить процессор, добавить памяти (а то и более мощный компьютер купить, если пхытон слишком тормозит на старом).

Краткое название всему этому — ориентирование на потребителя легкого поведения.

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

Очень узко мыслите. Вот прямо очень.

Прямо пример, который сразу приходит в голову - это парсер текстовых файлов - написан он будет на скриптовом языке очень быстро, отлажен очень быстро, а работать он будет очень надёжно. Это могут быть файлы конфигурации устройства на том же JSON или XML, приняли tar, распаковали его, обработали oneliner'ом, вычленили изменения настроек, применили. на том же perl это реально может быть oneliner - то есть, код в одну строку. Надёжно, протестировано, эффективно. Нужно раз в полгода, а-то и раз в несколько лет. Накладные расходы на использование скриптового языка получаются крайне низкими.

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

А вы пробовали? А мы да. У нас есть приложение, принимающее поток с камеры - по сути software-defined camera: на дивайсе вся обработка выключена, что с сенсора снято, то и отправляется на хост в "сыром" виде, цель - отработка алгоритмов обработки видеопотока. Приложение написано на Qt5. И есть вариант этого же приложения на PyQt5. Оба приложения ожирают в районе 9% производительности проца (плюс-минус процент). При этом на питоновом варианте функциональность даже побогаче, не говоря уже о возможности интерактивно работать с потрохами приложения через консоль, висящую в другом процессе.

Да, критичные места переписаны на С++, но там их всего ничего - три-четыре функции. Тормозов нет, потому что внутри всё равно работает оптимизированный код: что GUI'ая часть - библиотеки Qt, что numpy (видеокадры - массивы ndarray) - операции реализованы на С (хотя кое-что пришлось переписать, например, их функция построения гистограммы очень медленная для нас оказалась, она универсальная и навороченная, для интерактива годится, для потока нет, пришлось написать свою, там кода пять строк). В этом и фишка питона: это язык-фронтэнд. Не нужно стремиться писать на нём всё, нужно уметь правильно распределить код - нагруженные вещи реализовывать в оптимизированных модулях, а на самом питоне писать только управление этим. В этом суть pythonic философии. И не случайно питон занимает лидирующее место по количеству библиотек - буквально есть почти подо всё.


Ну, на вкус и цвет... Но насчёт хипстерского вы явно перегнули. У питона наиболее простой и человечный синтаксис из всего, что видел. Он просто акцентированно простой и неперегруженный синтаксическими элементами. Даже точки с запятой в конце выражений нет. Даже лексем для выделения блоков. Уж проще просто некуда. Даже проще чем в матлабе.

https://electronix.ru/forum/index.php?s=&am...t&p=1551035
Собственно, там ответ на ваш вопрос - на python не пробовал, и описано, как подобное реализовано в perl. И таки описано примерно то же, что и у вас, т.е. я со своей оценкой в 140%, что в python это решено образом, подобным примененному в perl, всё-таки попал в цель.

Так и есть- причем не могу не отметить что пример который Вы привели с камерой очень удачный: скажу больше, аналогичный подход есть и там где присутствует обработка "в камере", особенно если в ней х86 проц.

В моём понимании всё несколько иначе. В этом суть скриптовых языков вообще. А питонья философия - это то, что отличает питон от других скриптовых языков. Например, в perl - тим тоуди (всегда есть больше, чем один способ сделать что-либо), в python же - "Должен быть один - и желательно только один - очевидный способ сделать что-либо". Естественно, это не единственное изречение, описывающее "дзен языка Python".

Поддержу dxp, one_eight_seven и всех питонистов
+1 за Jupiter notebook.
У нас вся тестовая система "поднята" на питоне. Помимо этого проводим удаленное тестирование чипов на пластинах (относительно ответственная задача) с помощью питоновской среды.
Тут где-то на форуме была тема, как прикрутить питон к отладчику (емнип, STM32), чтобы можно было прямо через питон ногами дрыгать.

Питон всё-таки ненужен , для ембеддед жирноват-с.
Но это не значит что скриптовые языки - для эмбеддед не подходят. nodeMCU вон вполне себе удачно получилась.
Да и для обработки / анализа данных, что dxp описал, lua с питоном вполне потягаться может. см. torch.
Но вообще для этого есть mathematica, с более упоротым синтаксисом, правда, и позволяющая такой write-only код написать, что с brainfuckом разве что сравниться может.
Тем не менее для поиграться с обработкой и прототипированием, самое оно. позволяет делать в пару строк вещи которые на том же питоне выйдут куда многословнее.

В том то и дело, что вы тестовую среду сделали на питоне, чтобы при наличии огромных ресурсов на тестовом PC быстро наваять программу тестирования, не заморачиваясь в средах, синтаксисах и прочих делах.
Автор же спрашивает для Embedded, Вы по сути привели пример для полноценного компа.
Вы же тестовую среду не засовывается внутрь STM32 верно, так что не надо путать мухи яйца и котлеты.

Питон это высокоуровневый язык, парсер на питоне? С таким же успехом можно сделать на Java вот никакой разницы. И там и там крутится интерпретатор.
И для Embedded это конкретный геморрой на самом деле, нужна довольно жирная Linux и так далее. И там уже нет особой разницы, и скорее всего это уже не такой уж Embedded
Более того, если уж дело дошло до Python и parsing то зачем этот костыль, HTML >> Python >> XML когда можно внутри HTML использовать JS не прибегая к Python,
смысл городить сверху еще один интерпретатор.
Ах да ваш программист не знает JS но зато знает Python ну это конечно крутое решение.

Ну к примеру в GSM-модулях Telit встроенные Python в качестве скриптового языка. Аналогично сейчас есть вариант ESP32 c тем-же Python в качестве встроенного языка.

Собственно получается, что знание Питона требуется для embedded разработчика в случае, если он не чисто кодер, а занимается также тестированием, отладкой, проверкой концепций и всего остального, что легче сделать на компьютере, чем встроенной железяке и не важно надо будет при этом это переносить туда или это просто какая-то вспомогательная утилита. То есть нужна какая-то программа или скрипт на PC - за пять минут на Питоне написал и используешь. Не на Си же ее делать?
Например у меня даже разработчик firmware для ПЛИС отлично использует Питон в своих целях - снимает данные с Ethernet порта Wiresharkoм и потом их прогоняет через какие-то скрипты. Или из XML генерит bin-файл, который загружает в память плис через PCIe. В общем в вспомогательных вещах Питон очень пригодится.

Желающие могут прямо сегодня запустить микропитон на отладочной плате с STM32F4xx:
https://micropython.org/download
Как замена Ардуины - вполне годится.

А если как следует поколдовать над исходниками, то можно это дело встроить в свою программу на С/С++ и получить одновременно и производительность С и гибкость Питона там где они нужны.

Раскрою "страшную тайну": пхытон придумали для облегчения работы тем, кто вместо операционной системы использует на компьютере прошивку для игровых приставок. У них нет полноценного набора coreutils, нет возможности писать элементарные скрипты, вот они и выпендриваются!

Почему бы и нет?
Все алгоритмы обработки данных я, понятное дело, в интерпретаторе (octave) отлаживаю. Пусть это долго (и иногда приходится сильно урезать объем данных, чтобы не ждать результатов рассчета пару недель), зато потом, когда алгоритм отлажен, на С (при необходимости использовать GPU еще и на C++ — под nvcc) пишу за неделю-другую-четвертую обработчик. Вуаля — шустро и непринужденно.
Но это для вещей, с которыми часто надо работать. Если надо работать не чаще раза в пару месяцев, то могу и потратить целый день на полуавтоматизированную обработку чисто в octave.
Пхытон в моем случае был бы эдаким промежуточным вариантом: шустрей, чем в октаве, но все равно значительно медленней, чем на нормальном ЯП. А учитывая то, что у меня рвотный рефлекс на синтаксис пхытона, лучше при мне об этой дряни вообще не говорить (а то могу и заляпать ненароком)!!!

Да, для Ымбеда в малоресурсный МК Питон не годится. Мой пример был больше в копилку к примерам от dxp по поводу обработки данных и прочего.
Впрочем, Embedded сейчас очень разный. Например, у меня на Rpi (домашний сервер с мониторингом потребления газа и воды) почти все написано на Питоне, даже back-end для веб-морды (не умею я Java Script, да).



Вот это, кстати, неправда. Питон создавался без всяких привязок к "прошивке".


Меня тоже не все устраивает в синтаксисе Питона. Но его синтакс на три головы выше и продуманнее матлабовского (октавовского) - там вообще примитивнейший синтакс, никакого сахарку и т.п.


+1

Это в какой IDE вы там быстро можете отладить питон?
Питон - это дешевый заменитель более развитых инструментов.
Нишевой инструмент для определенного круга потребителей стесненных какими-то обстоятельствами: опенсорсом, бюджетом, навыками и т.д.
Если есть что-то на питоне, то это означает, что где-то есть более эффективное средство, которе пытаются воспроизвести на питоне.
Скажем Jupyter Notebook является бледным подобием Matlab Live View.
А pyOCD будет кривым подобием иснтрументов Segger для J-Link
GUI на питоне в подметки не годится GUI которое можно сделать на C# или на Delphi.
И так во всем.

Это откуда такой слоган? Ничего не мешает на питоне делать что угодно сколькими угодно способами.



Ну, питон с луной сравнивать как бы не совсем правильно. Питон плоховато подходит для встраивания в С/С++ - тяжеловат, не очень просто линкуется с объемлющим контекстом, в отличие от луны, которая в разы легче и имеет практически прямой доступ к сишному стеку. А вот как объемлющий-расширяемый язык питон имеет преимущества - более гибок (у луны по сути один тип на все случаи), несравнимо большее количество библиотек, прекрасно расширяется через С++ (так, что плюсовые объекты напрямую доступны из питона с очень хорошей производительностью - проводил замеры, т.к. нам было критично) сообщество намного шире. Т.ч. луна - встраиваемый язык, а питон - язык-манагер (фронтэнд).


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

PEP-20 же. Дзен питона. Я же написал же. https://www.python.org/dev/peps/pep-0020/
Ничего не мешает. Но это не приветствуется. Ничего не мешает делать отступы да и вообще оформлять код как заблагорассудится (в рамках синтаксиса, конечно), а не согласно PEP-8, но это крайне не приветствуется.

Вот как раз чем проще синтаксис, тем лучше!
Я начинал с бейсика (т.к. под мой псевдо-"ZX-спектрум" только так и можно было: бейсик + машкоды), в универе нас зачем-то пичкали паскалем (такое впечатление, что чтобы привить ненависть к программированию). Кое-что в фортране по ходу учебы пришлось делать (вот это жесть! но все равно понятней, чем пхытон). Потом были С и немного С++. Вот на С я и остановился как на наиболее адекватном языке программирования. Да еще и универсальном: я на нем пишу как прошивки для МК, так и консольные утилиты, обработчики данных, веб-службы, демоны и т.п.

Честно говоря, не представляю, как можно в разумные сроки изучить python. Особенно если уже знаешь С!

P.S. Единственным разумным применением пхытона я вижу рисование GUI: накалякал морду в qt-creator'е, потом при помощи пхытоновской прослойки к культям сделал...

и как там, всё работает с открытыми nouveau драйверами?
или же принципиальный непримиримый линуксоид понаставил себе закрытых проприетарных блобов от нвидии для игровых приставок ))

Да! На питоне многие вещи благодаря сахарку делаются гораздо проще и изящнее.


Все зависит от задачи и индвидуальных способностей обучающегося


Вам бы попробовать его сначала. ГУИ на питоне - дело десятое. И, кстати, к Питону разные ГУИ прикручиваются. У меня, например, WPFные гуи работают с питоном.


Странно, что при этом его встраивают как scripting language во многих CAD средах и ПО для обработки данных. Более странным является и тот факт, что Питон используют в крупных научных учреждениях. Например, в ЦЕРНе его применяют для обработки данных. Наверное, у тамошних нищебродов-ардуинщиков нет денег на нормальный тул, да и навыков не хватает.


Совершенно разные вещи. Матлаб примитивен как язык, создавать серьезные и сложные проекты особенно с GUI на нем сродни проектам на C++. Смешно сказать, матлабовский ГУЙ сделан на каких-то Java-костылях.
Matlab сейчас - это просто solution provider, не более.


Неправда. К Питону прикручиваются разные ГУИ, в том числе из WinForms и WPF.



обработчики сообщений приаттачиваются тем же оператором (+=), что и в C#. Питон, естественно, IronPython.

Я же говорю: лично для меня питон — бессмысленная трата времени! Зачем он мне нужен, если на С все намного шустрей получается, да и код я даже 10 лет спустя смогу прочесть и понять (чего не скажешь о пхытоне).
И, что очень важно: сишный код даже 20-летней давности я смогу скомпилировать. А пыхтоновский код даже через 10 лет вы уже не запустите!

Только что запустил код на python 2.6, но придётся подождать до 1 октября, чтобы проверить, что он перестал работать.

А, ну это мнение автора этого документа. Со многим там можно согласиться, но не со всем. Питон - обычный язык и средств там море. Имхо, тут больше подходит юниксовый принцип, что существует много способов сделать одно и то же (и каждый чем-то лучше в определённом контексте).


А он (матлаб) уже научился быть многопоточным?

Удар ниже пояса Пусть пользователи современного Матлаба ответят.

Может посоревнуемся?
Выкладывайте скриншоты ваших GUI на питоне.

ЦЕРН может себе позволить писать на чем хочет. Им эффективность до лампочки, у них проекты от 10 лет и до бесконечности длятся.
Так что не показатель.

Не вижу в этом смысла. У меня GUI делаются в C#, вызываются из Питона. Я вроде даже пример кода привел.
Никогда не видели Winforms и WPF? Или хотите удивить меня какими-нибудь виджетами из RAD Studio?

Боюсь, вы не правы: https://mail.python.org/pipermail/python-li...une/001951.html

Только для тех, кто не знает как обстоят дела с многопоточностью в Питоне.

PS. Модуль treading даёт только кооперативную многозадачность.
А настоящие потоки можно сделать только в подключаемых модулях написанных на С/С++.

В курсе что компоненты с COM интефейсом ( не путать с COM портом) уже всегда в своем потоке исполняются?


Нет, я хотел вот именно такой ответ.

Конечно. Запустите расчет коэффициентов какого-нибудь фильтра или просто обмен по COM (не путать с Component object model) в отдельном потоке.


Ну, слава богу. А то я подумал, что придется Вам рассказывать про то, как в C# GUI создаются.
Механизм-то, надеюсь, понятен?


Да, конечно. Но могло быть намного хуже (см Матлаб).

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


Если вы про GIL, так что с того? Потоки там нормальные, настоящие. Да, GIL не позволяет одновременно работать более, чем одному потоку, т.е. не получится раскидать потоки на разные ядра процессора так, чтобы они работали параллельно - всегда будет работать только один поток. По этой причине многопоточность питона не годится для выжимания максимальной производительности на вычислениях (для этого существует другие средства). Но типовые задачи, для которых рулит многопоточность - ввод-вывод, асинхронное выполнение задач и т.п. - прекрасно работают. Например, в моей нынешней программе помимо главного GUI потока крутятся

1. поток приёма видеокадров и их обработки;
2. поток команд через UDP на дивайс;
3. поток слежения за логами (внешние файлы).

Итого, 4 потока. Как на однопоточной платформе это реализовывать, не представляю.



Модуль threading даёт обычную нормальную вытесняющую многозадачность. Будь она кооперативной, мне бы пришлось вручную заботиться о том, чтобы отдавать управление в каждом потоке. Однако это не так: например, передача команд через UDP у меня вынесена в отдельный поток (чтобы не тормозить ожиданием отклика в GUI потоке), передача осуществляется через стандартный модуль queue, на приёмном конце поток встаёт на блокирующее ожидание из очереди, т.е. засыпает, пока в очереди ничего нет; как только на передающем в очередь что-то положили, приёмный поднимется и обработает задание.

Многопоточность в питоне из-за GIL похожа на многозадачность в каком-нить МК - в каждый момент времени может исполняться только один поток, т.к. ядро одно. Но это не отменяет вытеснения. Поэтому париться с отдачей управления вручную не требуется, и код писать вполне комфортно.

Справедливости ради надо сказать, что юниксовый принцип гласит: "Программа делает что-то одно, но делает это хорошо". Это совсем не то, что вы написали.

В принципе, нет особых препятствий тому, чтобы плевать в сахарницы. Просто это не приветствуется. А по поводу переписки - эта переписка, в которой определялись принципы, на которых строится сам язык. Поскольку авторам надоели постоянные просьбы "добавить в язык то или это", В переписке участвует и сам автор гвидопыха - Гвидо Ван Россум, а Тим Питерс - тот, кто записал эти напутствия. Да, как и любой документ "для информации" - он ничего жестко не регламентирует. Однако, при разработке Py3, согласно этому принципу были удалены многие дублирующиеся модули и конструкции. Но, в общем и целом - практическому применению питона в разных парадигмах (ООП, структурное программирование) это, конечно, не мешает. То есть, в плане "нет такого принципа" - вы не правы, а в том, что способы разные всё-таки есть - правы.

Там же не один принцип. Про программу - да. А мы не про программу говорили. Не отношу себя к знатокам традиций UNIX, но мне попадалась мантра "There is more than one way to do it" как один из философских принципов этой темы. Например:





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

тут не соглашусь, с метатаблицами у луа ещё посмотреть надо что там более гибкое.

тут пожалуй да, но есть ffi, swig, так что не самая большая проблема.

ну не знаю чем тут луа хуже дергать сторонние библиотеки, а вот с jit по скорости можно даже требовательные по скорости вычисления задачи решать прямо.
церн вон в части задач с питона перелез:
https://mediastream.cern.ch/MediaArchive/Vi...ftime=00:13:25#

ну это не я в качестве примера Jupyter привел

математика по сравнению с питоном класс задач может решать думаю не менее широкий.

это только пока код выглядит как
for i = 1, 10
a = b + c
а как только что-нибудь посерьёзнее, особенно если какие-нибудь учОные пишут что-нибудь для расчётов - тут всё.

Смотря как писать. SageMath - достаточно понятен (если понимаешь тему, в которой производятся вычисления/моделирование)

Естественно, блоб. Потому что нафиг покупать карту от nvidia, если нуво собираешься использовать?


Уже давно. Я, правда, octave использую, но друг сидит на матлабе. Там сейчас и CUDA вовсю работает на особо числодробильных алгоритмах, которые можно хорошо распараллелить!

Может у вас опыт от XP, но в API WinRT все коммуникации работают под COM т.е. в своих потоках.
C# да, достойный язык, тем более странно зачем тут нужен питон. За уши притягиваете?
Пока достойных примеров, кроме как желания вывалить в опенсорс я для питона не видел.
Это чем то напоминает хайп ардуинщиков.