Python для разработчика, зачем? Опции

[Dubov]

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

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

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

Сообщение отредактировал Dubov - Mar 13 2018, 14:15

[dxp]

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

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

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

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

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

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

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

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

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