Кроссплатформенная разработка на Python - есть ли проблемы?

есть, в доках обычно пишут platform specific notes.

>Пока получается минус в том, что нужен установленный интерпретатор python. Хоть для винды есть py2exe, но там получается большой вес исполняемого файла.

А в современных линуксах практически везде он уже стоит по умолчанию. Большой вес - это проблема только если HelloWorld'ы писать :)

> но там получается большой вес исполняемого файла

Когда Flickr появился в 2004-м году, он взорвал мой мозг

К тому моменту я прочитал все статьи, описывающие, как создавать страницы, которые быстро загружаются: уменьшение количества HTML'я, ручной тюнинг GIF'ок, повторное использование изображений. Я был погружен в культуру оптимизации конца 90-х. И вот вдруг появился сайт, который полностью основан на показе огромного количества фотографий, жадных до памяти. Более того, размеры этих фотографий полностью контролируются пользователями: изображения могут быть с увеличеной резкостью (over-sharpened), что серьезно увеличивает JPEG в размерах, или могут быть загружены с минимальной компрессией. Пользователи могут нажать на кнопку «все размеры» и насладиться 5-мегабайтовым фото. Сам факт просмотра 200-килобайтового изображения во много раз перевешивал любую попытку уменьшить количество обрамляющего HTML-кода

Пока я пытался понять, как это пропускные способности каналов прыгнули на такую недосягаемую высоту, как появился этот сайт, который делает то же, что и FLickr... но с ВИДЕО. И что теперь? Люди часами сидят, смотрят потоковое видео или целые 30-минутные серии различных сериалов онлайн. У Ютуба не только не было паранойи по поводу ширины каналов, но сама идея сайта как раз состояла в том, чтобы дать людям возможность запрашивать огромные объемы непрерывных данных. Такая идея была настолько вне зоны моего технического комфорта, которую я выстроил сам для себя, что я даже не смог бы начать думать о потенциальном ее существовании.

Этот урок я усвоил. И все же мне до сих пор попадаются люди, которые повторяют эту же ошибку, но в гораздо более консервативном исполнении:

— “На 64-битной машине каждый элемент списка в Эрланге равен 16 байтам, что совершенно недопустимо.“ — “Образ Smalltalk'а — 64 мегабайта, а это просто смешно. Я не собираюсь отправлять это нашим клиентам.“ — “Я никогда не буду использовать IDE, которая требует скачать 2 ГБ!“

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

> ...и технических беспокойств.

Ну как бы :) Беспокоит. Можно написать на C/C++ и получить вес кода 1М, а с python пользователю придется залить к себе 10-20М. Каналы не у всех всё-таки широкие (у меня лично нормальная скорость, я имею ввиду вообще). Хотя конечно уровень у python повыше будет и на нем приятнее и легче писать :)

> А в современных линуксах практически везде он уже стоит по умолчанию.

Да, это плюс :) Просто хочется, чтобы и у других не было проблем, если у них не линукс.

Ты хоть скажи, что собрался разрабатывать? А то какие-то странные претензии - размер большой. Вполне терпимый оверхед, по сравнению с жабой и моной.

Да это почти не претензии, я ж понимаю, что там типа возможностей много будет :)

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

Инсталляк питона 11Мб весит - а py2exe обычно в пределах 2Мб делает. Еще и сжать можно - если прога не хеловорлд - то оверхед вполне себе нормальный - скорее графическая либа (gtk или qt) больше займет.

А ну, если 2 метра, то это уже нормально =) (я просто еще не пробовал py2exe использовать, поскольку под линуксом)

Насчёт размеров при использовании py2exe:

$ ls -1sh
total 1.6M
865K python25.dll
701K sync.exe

sync.exe - обновлялка через ftp, на питоне.

Для графических приложений (например, с использованием wxgtk) размеры начнутся от 6-7 MB.

>Для меня такие заявления — то письменное подтверждение чьих-либо произвольных ограничений и технических беспокойств. Такие заявления практически никогда не имеют какого-либо отношения к реальности и к тому, что будет успешным, а что — нет.

ага, видел я приверженцев такого подхода. сайт с цитатами(текстовая информация, никаких картинок!) был сделан на веб2.0 и кое-как шуршал страницами, у ютуба с видео наполнением отклик и то был выше.

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

Когда я делал инсталляшку для своего приложения с GUI (pygtk), размер получился 4.8М (16.7М в развернутом виде). При этом я для каждого файла, методом удаления, узнал нужен он или нет

недавно писал нагрузочного тестового тисипи-клиента , с использованием твистед
код составил буквально 20 строк
потом переписал это полностью на си - получилось кода аж 2 страницы
питон весьма лаконичен

главное это не забить на оптимизацию, а чётко представлять когда она нужна а когда нет. Уж очень много примеров видел когда народ потом хвататлся за голову в попытках понять как это можно ускорить или хотя бы кластеризовать :)

Особых проблем нет, в основном по-мелочам типа неработающий os.popen в win32.

а еще разный принцип форканья в винде и линуксе

я вижу только 1 проблему - извращенные имена с подчёркиваниями :)

>я вижу только 1 проблему - извращенные имена с подчёркиваниями :)

И отступы, отступы же:)

Хм, а можно ли сделать препроцессор для {} в отступы? Или уже может кем то изобретено?

> Хм, а можно ли сделать препроцессор для {} в отступы? Или уже может кем то изобретено?

Сделать то можно, но тогда python уже не будет так красив :)

> И отступы, отступы же:)

это не проблема
это мелочь

> Для меня такие заявления — то письменное подтверждение чьих-либо произвольных ограничений и технических беспокойств. Такие заявления практически никогда не имеют какого-либо отношения к реальности и к тому, что будет успешным, а что — нет.

Серьезное "но": потоковое видео, хотя и прокачивает допустим 1000М в час, позволяет увидеть результат в первые же секунды. Однако, если ты сделаешь "бесплатно попробуйте" игрушку на смоллтолке с инсталлятором в 100М, не факт, что ее вообще скачают. Ибо долго.

> Сам факт просмотра 200-килобайтового изображения во много раз перевешивал любую попытку уменьшить количество обрамляющего HTML-кода

Опять упущен серьзный момент. Гугль скорее всего имеет географически распределенную систему для уменьшения нагрузки на свой сервис. Вася пупкин же (или даже godaddy.com), сделавший 200-к html странички, столкнется с тормозами -- хостинг в америке/канаде, а пользователи -- в россии.

> Хм, а можно ли сделать препроцессор для {} в отступы? Или уже может кем то изобретено?

лучше побольше скобок добавить

У меня тот же вопрос, но по отношению к Python/Jython/Iron Python. Хочется иметь некоторый набор функционала на чисто питоне и "родную" для соответствующей среды морду, которая, конечно, будет писаться для каждой платформы отдельны.

> Опять упущен серьзный момент.

Вообще, поинт того сообщения был не в том, что надо полностью забивать на оптимизацию и поиск более оптимальных решений, а в том, что как говаривал Дон Кнут "Premature optimization is the root of all evil". Думать только о быстродействии и занимаемой памяти и считать это основным критерием нужности/ненужности, без оценки профита, которого дает то или иное решение -- глупо, вот и все.

єто уже есть http://timhatch.com/projects/pybraces/

ах, да. попробуй это:
from __future__ import braces