Comments 18
Файлы .pyw с точки зрения интерпретатора абсолютно ничем не отличаются от файлов .py. Единственное отличие — в Windows (а в других ОС файлы .pyw вообще не используются) по умолчанию запускается интерпретатор без консольного окошка. Вот и всё.
Вот и всё.
Не все! Он не просто «запускают интерпретатор без консольного окошка», но и выводят полноценный оконный интерфейс, если таковой присутствует в скрипте.
Это достаточно круто! В поставке третьей версии Питона есть файлы: \Lib\idlelib\idle.pyw – встроенный «графический» Питон, и \Tools\pynche\pynche.pyw – пример отображения пользовательской графики.
На гитхабе можно найти более продвинутые примеры. Причем текстовые файлы *.pyw можно компилировать в автономные экзешники. Да, файлы получаются огромные, и не слишком, может быть, шустрые, но зато клиентскую графику можно делать почти с «пол-пинка».
Не все! Он не просто «запускают интерпретатор без консольного окошка», но и выводят полноценный оконный интерфейс, если таковой присутствует в скрипте.
А что же ещё? Вы же сами написали, что графический интерфейс будет только тогда, когда код для его создания есть в скрипте.
Зачем спорить, если можно проверить? Вот вы пишете про idle.pyw. Попробуйте скопировать его куда-то. Если запустите — откроется мини-IDE. Если потом переименуете этот файл в idle.py и запустите, это тоже сработает, просто на фоне ещё будет маячить консоль.
Причем текстовые файлы *.pyw можно компилировать в автономные экзешники. Да, файлы получаются огромные, и не слишком, может быть, шустрые, но зато клиентскую графику можно делать почти с «пол-пинка».
Если вы про cx_Freeze и аналоги, то это не компиляция, а просто упаковка интерпретатора и кода в один большой файл. Но они работают и с .py, и с .pyw.
Для интерпретатора вообще нет разницы, какое расширение. Единственная разница в том, что в Windows эти файлы ассоциированы с разными исполняемыми файлами (py.exe/pyw.exe), отличие между которыми — это то, что один открывает консоль, а другой нет. Ну, и конечно, есть некоторые отличия в работе с stdin/stdout. Это следствие того, что консоли нет.
Исполнение самого кода абсолютно такое же.
Однако от использования клиентского GUI на Питоне, я решил отказаться. Это, конечно, не самый худший вариант из возможных, но есть лучшее, которое, «враг хорошего». Интерфейс я делаю на C++ / WTL и вполне успешно, использовать другие фрейморки пока не хочу. А Питон мне нужен только как превосходное средство для работы с текстом, по сути, для обработки данных. Тут ему цены нет. На С++ это делать тоже можно, и я делал, но было дольше и труднее. Да, еще я Питон использовал (в паре с ImageMagick и FFmpeg) для пересборки обучающих видео (двуязычные субтитры, повторы и паузы). PotPlayer это тоже делает (я генерировал для него скрипты на том же Питоне), но хуже. А на WTL я заканчиваю вторую версию (первая была на AIR / Flex) программы для моего метода «запоминание руками». Если интересно, то могу дать ссылки (хотя в прошлых комментариях на Хабре, я об этом уже писал).
Мне кажется что вы упустили описание шага компиляции в питон модуль
Всё это ускорение выглядит красиво, но только до тех пор, пока вычисляем фибоначчи/факториалы. Как себя поведёт Nim, если нужно будет обернуть в декоратор с параметрами метод с вычисляемым именем у класса с наследованием от трёх классов, созданных метаклассами?
А чтобы ускорить фибоначчи, тожно просто загуглить Cython или использовать fast doubling.
Есть еще такая тема https://github.com/juancarlospaco/faster-than-requests
Ускоряем код на Python с помощью Nim