[_pv 52]

на С (при необходимости использовать GPU еще и на C++ — под nvcc)

и как там, всё работает с открытыми nouveau драйверами?

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

 

[alexunder 4]

Вот как раз чем проще синтаксис, тем лучше!

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

 

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

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

 

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

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

 

Нишевой инструмент для определенного круга потребителей стесненных какими-то обстоятельствами: опенсорсом, бюджетом, навыками и т.д.

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

 

Скажем Jupyter Notebook является бледным подобием Matlab Live View.

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

Matlab сейчас - это просто solution provider, не более.

 

GUI на питоне в подметки не годится GUI которое можно сделать на C# или на Delphi.

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

 

import clr;
clr.AddReference('ElfeezVisualTools.dll');
from ElfeezVisualTools import ElfeezStudio;

def enable_studio(self):
    """ Enables Elfeez Studio """
    self.studio = ElfeezStudio.New();
    self.studio.eventStartStreaming += self._studio_start_streaming;
    self.studio.eventStopStreaming += self._studio_stop_streaming;
    self.studio.eventToggleCounting += self._studio_toggle_counting;
    self.studio.eventToggleChipPower += self._studio_toggle_chip_power;
    self.studio.eventResetCounters += self._studio_reset_counters;
    self.studio.eventResetTimeStamp += self._studio_reset_time_stamp;
    self.studio.eventPixelPropertyChanged += self._studio_pixel_property_changed;

 

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

[Eddy_Em 1]

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

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

[one_eight_seven 3]

А пыхтоновский код даже через 10 лет вы уже не запустите!

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

[dxp 34]

PEP-20 же. Дзен питона. Я же написал же. https://www.python.org/dev/peps/pep-0020/

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

 

Matlab сейчас - это просто solution provider, не более.

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

[alexunder 4]

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

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

[AlexandrY 3]

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

Может посоревнуемся?

Выкладывайте скриншоты ваших GUI на питоне.

 

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

Так что не показатель.

[alexunder 4]

Может посоревнуемся?

Выкладывайте скриншоты ваших GUI на питоне.

Не вижу в этом смысла. У меня GUI делаются в C#, вызываются из Питона. Я вроде даже пример кода привел.

Никогда не видели Winforms и WPF? Или хотите удивить меня какими-нибудь виджетами из RAD Studio?

[one_eight_seven 3]

А, ну это мнение автора этого документа.

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

[SSerge 4]

Удар ниже пояса :)

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

 

PS. Модуль treading даёт только кооперативную многозадачность.

А настоящие потоки можно сделать только в подключаемых модулях написанных на С/С++.

[AlexandrY 3]

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

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

 

Не вижу в этом смысла. У меня GUI делаются в C#, вызываются из Питона. Я вроде даже пример кода привел.

Никогда не видели Winforms и WPF? Или хотите удивить меня какими-нибудь виджетами из RAD Studio?

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

[alexunder 4]

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

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

 

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

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

Механизм-то, надеюсь, понятен?

 

PS. Модуль treading даёт только кооперативную многозадачность.

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

 

[dxp 34]

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

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

 

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

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

 

1. поток приёма видеокадров и их обработки;

2. поток команд через UDP на дивайс;

3. поток слежения за логами (внешние файлы).

 

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

 

 

PS. Модуль treading даёт только кооперативную многозадачность.

А настоящие потоки можно сделать только в подключаемых модулях написанных на С/С++.

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

 

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

[andrew_b 14]

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

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

[one_eight_seven 3]

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

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