Здравствуйте, Polymorphic, Вы писали:
P>Кто-нибудь использует? Интересуют в основном грабли и что для GUI.
Ну так а как же Dropbox?
Originally, both the Dropbox server (running on the cloud) and desktop client software were primarily written in Python.[52] From mid-2013 Dropbox began migrating its backend infrastructure to Go.[3] The desktop client uses Python GUI toolkits such as wxWidgets and Cocoa. Other notable Python libraries include Twisted, ctypes, and pywin32. Dropbox ships and depends on the librsync binary-delta library (which is written in C). Dropbox’s full browser-side codebase is written in CoffeeScript instead of JavaScript.[53]
9+ летней давности. Там как-то без особых восторгов было.
Граблей будет много, особенно по первости. Со всякими так PyPy и прочими радостями "простого и незаметного компилирования кода на Python в код на Си". Плюс еще динамический язык со всемы вытекающими особенностями.
Я правильно поинмаю, что планируется что-то глобально кроссплатформенное?
Здравствуйте, Polymorphic, Вы писали:
KP>>Я правильно поинмаю, что планируется что-то глобально кроссплатформенное? P>Да, если конечно будет интерес у целевой аудитории.
Если это затевается только ради кроссплатформенности, но чем не устраивает С++?
Здравствуйте, Polymorphic, Вы писали:
P>Кто-нибудь использует? Интересуют в основном грабли и что для GUI.
Ну я использую, python + pyside(это опенсорсная qt под питон), компилируется с помощью pyinstaller. Плюс у меня там numpy/scipy для алгоритмов.
Писать намного удобнее и быстрее чем на плюсах. Грабли — приходится в отдельных местах заморачиваться с производительностью там, где на плюсах с приемлемой скоростью работал бы самый тупой алгоритм. Ну и надо понимать, что любой желающий сможет декомпилировать прогу в исходники.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, drVanо, Вы писали:
V>Если это затевается только ради кроссплатформенности, но чем не устраивает С++?
До кроссплатформенности дойдет, если действительно начнет взлетать (но я надеюсь).
Можно и на С++, но хочется же чего-то нового посмотреть. В интернетах пишут, что вроде у питона есть богатые библиотеки.
P>можно компилировать питон в си и дальше компилировать си в нативный код. реверсить такой код сложно будет.
Я не знаю таких решений, которые бы взяли полноценный питоновский проект со сторонними библиотеками и скомпилировали его в си или в натив.
Отдельные участки кода действительно можно вынести в библиотеки, специально подготовить и скомпилировать, но их можно и сразу на плюсах написать и грузить как dll.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, Polymorphic, Вы писали:
P>Писать планирую десктопное приложение, использующее API нескольких SaaS.
Если один эз этих SAAS твой, то писать становится абсолютно все равно на чем.
Здравствуйте, alexdpp, Вы писали:
A>Sublime text написан на питоне, поддерживает Win/Mac/Linux, 32/64 bits
Википедия подсказывает, что не на Питоне, а на C++ и Питоне: http://en.wikipedia.org/wiki/Sublime_Text
Совершенно попсовая практика — весь хардкор написать на чём-то одном, а потом сверху прикрутить какой-нибудь JS.
Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
9+ летней давности. Там как-то без особых восторгов было.
P>Писать планирую десктопное приложение, использующее API нескольких SaaS.
С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап.
2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
Здравствуйте, andyag, Вы писали:
A>Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, andyag, Вы писали:
A>>Более того, Sublime скорее загнулся, чем не загнулся — последний билд версии 3 был 29 августа 2014. Можно предположить, что Питон проклят.
Н>4 февраля
Здравствуйте, andyag, Вы писали:
A>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
Ты не прав. Инструмент очень удачный. Он простой в изучении, он относительно прост в поддержке и он базируется, наверное, на самых правильных принципах в разработке ПО, какие только можно придумать (PEP 20). А еще у них есть замечательные IPython с Notebook.
A>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап. A>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
Проблема есть, она, иногда, создает неудобства. Но я бы не сказал что это что-то критическое, сколь-нибудь сильно мешающее разработке на нем.
A>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
Менеджер как менеджер. Не самый лучший, но однозначно выполняющий свою задачу. Пакетов в нем много, у меня не так что бы очень уж обширный Python опыт, но почти все находилось. Плюс еще можно поставить Конду и вообще жизнь станет прекрасной.
A>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.
A>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
Зачем переписывать? Есть серьезное подозрение что проблема в не умении его готовить, а не самом языке.
A>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
А почему для более сложных задач нельзя? На нем можно великолепно писать всяческие считалки (привет NumPy с Pandas) так и сервера (тут очень интересен Twisted). Единственное о чем бы я 10 раз подумал, перед тем как писать на Python – GUI приложения. У меня есть подозрения (не пробовал, только гадать могу), что в этой области выйдет не очень.
A>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
Python обладает более обширной библиотекой (за пределами разработки Web-сайтов) чем Ruby и он слегка шустрее. Я бы не сказал что у Ruby есть какие-то серьезные преимущества, как минимум до тех пор, пока ты Рельсы не хочешь использовать.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, andyag, Вы писали:
A>>С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент.
KP>Ты не прав. Инструмент очень удачный. Он простой в изучении, он относительно прост в поддержке и он базируется, наверное, на самых правильных принципах в разработке ПО, какие только можно придумать (PEP 20). А еще у них есть замечательные IPython с Notebook.
Zen of Python неявно существует в абсолютно любом ЯП. Главное чтобы автор кода верил, что придерживается этого дзена — тогда у него есть гармония. Но читатели кода часто несогласны, что написанный код имеет какое-то отношение к дзену и вульгарно называют код — говнокодом.
A>>1. Комьюнити уже 6 лет не может переехать с версии на 2 на версию 3 — это самый большой факап. A>>2. Из-за п.1 часть старых зрелых библиотек не доступна на Python 3.
KP>Проблема есть, она, иногда, создает неудобства. Но я бы не сказал что это что-то критическое, сколь-нибудь сильно мешающее разработке на нем.
Это снова что-то сильно субъективное. Если оно не мешает вашим кейзам, это не значит, что оно не мешает вообще. Это как-то нездорово — чувствовать себя спокойно, когда знаешь, что завтра может понадобиться какая-то библиотека для XXX, которой может не быть для Python 3, в то время как остальная часть проекта уже написана именно на 3. Это просто ненормально.
A>>3. У Python нет адекватного менеджера зависимостей. Есть убогий pip, который выглядит как недоделанный костыль (если сравнивать с аналогами для других языков). Хрен с ним, что костыль, но далеко не все библиотеки через него доступны.
KP>Менеджер как менеджер. Не самый лучший, но однозначно выполняющий свою задачу. Пакетов в нем много, у меня не так что бы очень уж обширный Python опыт, но почти все находилось. Плюс еще можно поставить Конду и вообще жизнь станет прекрасной.
Просто чтобы я мог оценить ваше высказывание в полной мере — когда вы говорите "не самый лучший", какой "самый лучший" вы имеете в виду?
A>>Python можно рассматривать как тул для реализации логики отдельных частей приложения: весь хардкор написать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%, а потом скрутить этот хардкор в кучу через Python. Например есть реализация Python на Java — Jython. Но с таким же успехом там есть и JavaScript, и JRuby и ещё штук 10 менее попсовых языков.
KP>Нет-нет и еще раз нет. Python можно и нужно рассматривать как основной кандидат для написания не критичной ко скорости логики. Именно по тем причинам, что я привел в самом начале.
Не понял с чем вы спорите — я сказал почти то же самое. Более того, тут вы подтверждаете мое самое первое утверждение — "С практической точки зрения нет смысла рассматривать Python как самостоятельный инструмент".
A>>Python можно рассматривать как тул для всяких экспериментов — типа запрограммировать алгоритм, посмотреть как он работает, а потом переписать на %ТУТ ВАШ ЛЮБИМЫЙ ЯП%. У него есть какие-то там интересные математические библиотеки, поэтому для таких задач оно может иметь смысл.
KP>Зачем переписывать? Есть серьезное подозрение что проблема в не умении его готовить, а не самом языке.
И нафига мне алгоритм на Python, если остальной код написан, например, на C#? Проясню ситуацию: я делаю какой-то проект на C#, возникает необходимость запилить какой-то не очень тривиальный алгоритм. Я хочу сначала пощупать этот алгоритм, проверить на разных данных, порисовать какие-то графики — в этом случае я возьму Python. Но как только нащупаюсь, перепишу всё на C#.
A>>Python можно рассматривать как тул для скриптов, замену всяким *.bat и *.sh, т.к. стандартная библиотека у него вполне интересна — многое можно сделать в 2 строчки без запуска внешних процессов и разбора их вывода через grep и прочие ужасы. Но примерно с таким же успехом можно использовать и тот же Ruby, и Groovy, и даже NodeJS при должной мотивации.
KP>А почему для более сложных задач нельзя? На нем можно великолепно писать всяческие считалки (привет NumPy с Pandas) так и сервера (тут очень интересен Twisted). Единственное о чем бы я 10 раз подумал, перед тем как писать на Python – GUI приложения. У меня есть подозрения (не пробовал, только гадать могу), что в этой области выйдет не очень.
Ни разу не спорю, что можно. Вопрос в том, какая должна быть мотивация, чтобы выбрать Python, а не что-то другое. Если про NumPy мне возразить нечего (и не хочу — см. предыдущий пункт про "алгоритм"), то тот же Twisted — это совершенно точно не киллер-фича Python. Сейчас практически на любой платформе есть своё супер-производительное асинхронное решение для построения сетевого фасада. Но у многих из этих платформ ещё и нет недостатков, описанных выше, поэтому зачем Python?
A>>ИМХО, Python это недо-Ruby, а Ruby в свою очередь очень сильно на любителя. По-моему в случае с десктопом лучше не изобретать велосипед, а использовать всякие общепринятые сиплюсплюсы, кьюты, или вообще дотнеты.
KP>Python обладает более обширной библиотекой (за пределами разработки Web-сайтов) чем Ruby и он слегка шустрее. Я бы не сказал что у Ruby есть какие-то серьезные преимущества, как минимум до тех пор, пока ты Рельсы не хочешь использовать.
Тут снова достаточно возразить, что у Ruby как минимум нет проблем 2 vs. 3, огроменный централизованный репозиторий с кучей библиотек и тот самый, упомянутый вами, RoR. Даже если согласиться, что Ruby и Python примерно одинаковы, окей, почему Python, а не Ruby?
A>Совершенно попсовая практика — весь хардкор написать на чём-то одном, а потом сверху прикрутить какой-нибудь JS.
Ты не понял. Критичный "хардкор" пишется на языке низкого уровня. Остальная часть на (предметно ориентированном) языке более высокого уровня.
