Comments 38
В питоне есть несколько родовых травм, которые до сих пор не могут преодолеть.
Первое: строки
Второе: дистрибуция пакетов
Третье: медленный старт приложений из-за import'ов всего и вся (речь про сотни милисекунд, и это много для некоторых применений).
Четвёртая травма не родовая, но уж очень глубокая: это фактически мёртвый python3, и декларативно мёртвый python2.
Первое: строки
Второе: дистрибуция пакетов
Третье: медленный старт приложений из-за import'ов всего и вся (речь про сотни милисекунд, и это много для некоторых применений).
Четвёртая травма не родовая, но уж очень глубокая: это фактически мёртвый python3, и декларативно мёртвый python2.
Зря это ты
Зря что? Правду пишу?
Остаётся объяснить каждому начинающему на питоне, как сделать print «Привет мир» без странных звёздочек с дефисами, как запакетировать смешанную бинарно-питоновую библиотеку и как запустить приложение на питоне за 1-2 милисекунды, и вопросов к питону больше не будет.
Остаётся объяснить каждому начинающему на питоне, как сделать print «Привет мир» без странных звёздочек с дефисами, как запакетировать смешанную бинарно-питоновую библиотеку и как запустить приложение на питоне за 1-2 милисекунды, и вопросов к питону больше не будет.
Зря пишешь не по теме. Описан конкретный вопрос, а ты уходишь в демагогию о недостатках языка и платформы в целом. Разжигание холивара это называется. Может, даже неумышленное, но все же
#coding utf8
“Странные звёздочки с дефисами” — это, кажется, аналог modelines для какого‐то редактора (emacs?). Можно с тем же успехом использовать ́
Хотя «привет мир» без звёздочек с дефисами и вообще без не‐ASCII можно очень легко сделать: просто сразу скажите новичку, как использовать gettext и писать многоязычные приложения :) Разумеется, все сообщения в коде будут на английском.
Проблемы есть, но они решаются. И их меньше, чем во многих других языках. Есть отличная практика, которая убережёт вас от минусов за разжигание священных войн: как только вам захочется написать подобное не соответствующее теме сообщение (не важно, насколько оно правдиво), возьмите какой‐нибудь shell скрипт длиною хотя бы в десяток строк и перепишите его для работы на tcsh. Уверяю, после данного действия все прочие скриптовые языки станут казаться верхом совершенства.
# vim: fileencoding=utf-8. С python3 не нужно и того (вы либо пишете в UTF-8, либо вас посылают с SyntaxError).Хотя «привет мир» без звёздочек с дефисами и вообще без не‐ASCII можно очень легко сделать: просто сразу скажите новичку, как использовать gettext и писать многоязычные приложения :) Разумеется, все сообщения в коде будут на английском.
Проблемы есть, но они решаются. И их меньше, чем во многих других языках. Есть отличная практика, которая убережёт вас от минусов за разжигание священных войн: как только вам захочется написать подобное не соответствующее теме сообщение (не важно, насколько оно правдиво), возьмите какой‐нибудь shell скрипт длиною хотя бы в десяток строк и перепишите его для работы на tcsh. Уверяю, после данного действия все прочие скриптовые языки станут казаться верхом совершенства.
Первое: строки
Второе: дистрибуция пакетов
Третье: медленный старт приложений из-за import'ов всего и вся (речь про сотни милисекунд, и это много для некоторых применений).
Честно говоря, не ощущаю проблем при работе со строками. И с пакетами беды возникают только под Windows (но это общая проблема OpenSource проектов, когда разработчики не заботятся о поддержке Windows).
А если вам не нравится медленный старт, то может не стоит скрипт останавливать? И по поводу долгой инициализации, вы ещё не видели, как стартует JBoss сервер, поднимая EJB контейнеры, инициализируя Beans, Hibernate, RESTExpress и всё, всё, всё.
Четвёртая травма не родовая, но уж очень глубокая: это фактически мёртвый python3, и декларативно мёртвый python2.
Странно, уже вышел Python 3.4.0 beta 3, а вы говорите, что язык мёртвый.
Недавно был топик, что число используемых в продакшене 3их питонов стремится к нулю, а все сидят на 2.4-2.7, и даже началось шебуршение на тему «сделать 2.8 с фичами из 3 и варнингами про депрекейтеды 2->3». И, вроде, на lwn была статья на тему, как пытаются прикрутить к bytearray оператор % назад, чтобы вернуть обратную совместимость с кодом на питоне.
Собственно, вот она: lwn.net/SubscriberLink/581475/e17810225a457e9c/
Собственно, вот она: lwn.net/SubscriberLink/581475/e17810225a457e9c/
Давайте называть вещи своими именами: мёртвый язык — некогда использовавшийся язык, вышедший из употребления. Потому следует говорить о Python 3, скорее, как о языке не получившем [пока] широкого распространения. Python 2, кстати, тоже ещё долго не станет мёртвым (бьюсь об заклад, что даже после окончания периода поддержки).
Через этот этап, когда язык не имеет широкого распространения, прошли все языки, так давайте просто посидим тихо и понаблюдаем (кто-то с опаской пассивно, кто-то продвигая и развивая язык), что будет дальше: умрёт он в итоге, или наберёт форму. А просто раскачивать лодку смысла мало — разве только из праздности.
Впрочем, как бы ни были неудобны слова Гейнора, Ронахера и др. о Py3, всё же они во многом справледливы. В этом их ценность — они являются обратной связью для создателей Py3, качественной обратной связью с указанием на конкретные промахи и даже вариантами выхода из сложившейся ситуации. Увидим, в общем ;)
Через этот этап, когда язык не имеет широкого распространения, прошли все языки, так давайте просто посидим тихо и понаблюдаем (кто-то с опаской пассивно, кто-то продвигая и развивая язык), что будет дальше: умрёт он в итоге, или наберёт форму. А просто раскачивать лодку смысла мало — разве только из праздности.
Впрочем, как бы ни были неудобны слова Гейнора, Ронахера и др. о Py3, всё же они во многом справледливы. В этом их ценность — они являются обратной связью для создателей Py3, качественной обратной связью с указанием на конкретные промахи и даже вариантами выхода из сложившейся ситуации. Увидим, в общем ;)
Сплетни-сплетни-сплетни.
А практика такова что python 3.3 даёт уже больше плюшек чем проблем.
А практика такова что python 3.3 даёт уже больше плюшек чем проблем.
Я как более сисадмин, чем программист, могу сказать, что python3 я в продакшене просто не вижу. Не используют-с.
у вас нету, у нас есть. Вывод?
Вы про самописный код? Я про то, что в репозиториях. (Для исключения разногласий, уберём библиотеки).
В Gentoo в репозиториях очень даже есть python3.
Точнее все проекты, поддерживающие запуск на python3 можно установить для python3, python2 или (за исключением некоторых) вообще для всех поддерживаемых версий python сразу, включая pypy и jython (правда, поддержку последних часто не указывают, даже если на них всё работает). У меня в /usr/lib/python-exec/python3.3 находятся 55 скриптов. Таже 56 у python3.2, 57 у python2.6 и 59 у python2.7, что говорит о хорошей поддержке третьего python среди используемых мною пакетов (их 19, 20, 21 и 22 соответственно для 3.3, 3.2, 2.6 и 2.7). И всё, что есть в /usr/lib/python-exec, установлено emerge.
Правда, я не вижу Gentoo в продакшене. Но в её репозиториях всё есть — факт :)
Точнее все проекты, поддерживающие запуск на python3 можно установить для python3, python2 или (за исключением некоторых) вообще для всех поддерживаемых версий python сразу, включая pypy и jython (правда, поддержку последних часто не указывают, даже если на них всё работает). У меня в /usr/lib/python-exec/python3.3 находятся 55 скриптов. Таже 56 у python3.2, 57 у python2.6 и 59 у python2.7, что говорит о хорошей поддержке третьего python среди используемых мною пакетов (их 19, 20, 21 и 22 соответственно для 3.3, 3.2, 2.6 и 2.7). И всё, что есть в /usr/lib/python-exec, установлено emerge.
Правда, я не вижу Gentoo в продакшене. Но в её репозиториях всё есть — факт :)
А какая разница что там в репозиториях? В арче я уверен py3 тоже есть.
В убунте репозиторий всегда остаёт от реалий, по понятным причинам.
Изначально же я говорил про наш продакшн, ибо думал вы о нём.
В убунте репозиторий всегда остаёт от реалий, по понятным причинам.
Изначально же я говорил про наш продакшн, ибо думал вы о нём.
Пишу из 2020, Python живее всех живых.
А каким образом вы определяете, что он живой? Вот тут вот говорят, что python2.7 не имеет никакого статуса.
Как минимум, по количеству поисковых запросов: trends.google.ru/trends/explore?date=2014-06-14%202020-07-14&geo=RU&q=python
Не Python умер, а python2 умер.
https://trends.google.ru/trends/explore?date=2014-06-14%202020-07-14&geo=RU&q=python,python2
Для меня это выглядит слишком мудрено. Мы считаем что единственно правильный
путь распространения пакетов для Linux это deb/rpm.
FPM делает создание пакетов тривиальным.
Мы даже не используем virtualenv — вполне достаточно установить PYTHONPATH.
путь распространения пакетов для Linux это deb/rpm.
FPM делает создание пакетов тривиальным.
Мы даже не используем virtualenv — вполне достаточно установить PYTHONPATH.
«мы» это кто?
Мы, dmitriko
Как я понял, идет обсуждение способа распространения Python приложений.
Я, в составе небольшой группы единомышленников, занимаюсь этим много лет.
И с высоты нашего опыта использование любых способов кроме
rpm/deb выглядит крайне недальновидно. По множеству причин.
Я говорю «мы» потому что сам когда то предлагал использовать eggs, virtualenv, etc.
Но старшие товарищи поправили ;)
Ну а wheels _лично_ мне показались излишне сложным решением.
Остались ли еще не ясные моменты в моих комментариях?
Я, в составе небольшой группы единомышленников, занимаюсь этим много лет.
И с высоты нашего опыта использование любых способов кроме
rpm/deb выглядит крайне недальновидно. По множеству причин.
Я говорю «мы» потому что сам когда то предлагал использовать eggs, virtualenv, etc.
Но старшие товарищи поправили ;)
Ну а wheels _лично_ мне показались излишне сложным решением.
Остались ли еще не ясные моменты в моих комментариях?
virtualenv удобен, если на одной машине у вас несколько независимых проектов. К примеру это staging сервер со всеми выпущенными проектами. Суть в изоляции пакетов одного проекта от другого.
setuptools/pkg_resources это не только пакеты egg/wheel, это еще и entry points, и многое-многое другое. Через entry points удобно расширять другие пакеты/приложения (группа console_scripts), публиковать WSGI приложения/фильтры, так продолжать можно долго. За примером можно к Pyramid. Да и публиковать приложение лучше как egg/wheel, а не архивом файлов или целого virtualenv.
Впрочем, в питоне никто не обязывает следовать одному рецепту, лишь бы выбор не мешал работать.
setuptools/pkg_resources это не только пакеты egg/wheel, это еще и entry points, и многое-многое другое. Через entry points удобно расширять другие пакеты/приложения (группа console_scripts), публиковать WSGI приложения/фильтры, так продолжать можно долго. За примером можно к Pyramid. Да и публиковать приложение лучше как egg/wheel, а не архивом файлов или целого virtualenv.
Впрочем, в питоне никто не обязывает следовать одному рецепту, лишь бы выбор не мешал работать.
Согласен практически со всем. В разработке без virtualenv не обойтись.
Может дело личного вкуса, но для меня Pyramid и entry points
привносят слишком много магии. И получается что установка и
настройка OpenStack, который использует Pyramid, превращается
в нетривиальную задачу.
Но, наверное, главная причина по которой мы не используем eggs
заключается в том, что наши приложения часто устанавливают третьи лица,
которые и знать не хотят что там внутри Python. А так как речь
идет о множестве машин, то установка и обновление идет через Puppet, Chef
etc которые работают c RPM из коробки.
Может дело личного вкуса, но для меня Pyramid и entry points
привносят слишком много магии. И получается что установка и
настройка OpenStack, который использует Pyramid, превращается
в нетривиальную задачу.
Но, наверное, главная причина по которой мы не используем eggs
заключается в том, что наши приложения часто устанавливают третьи лица,
которые и знать не хотят что там внутри Python. А так как речь
идет о множестве машин, то установка и обновление идет через Puppet, Chef
etc которые работают c RPM из коробки.
Мы даже не используем virtualenv — вполне достаточно установить PYTHONPATH.— Можно тогда уж импорты не использовать, а все необходимые объявления копировать в ваш Файл.
Мне не понятен Ваш сарказм. Вот как это работает у нас:
RPM кладет приложение в /var/lib/appname
При этом в эту же директорию помещаются наши модули,
/var/lib/appname/foo, /var/lib/appname/bar,…
Init script устанавливает переменную окружения PYTHONPATH=/var/lib/appname
После этого import foo, import bar просто работают.
И зачем здесь virtualenv?
RPM кладет приложение в /var/lib/appname
При этом в эту же директорию помещаются наши модули,
/var/lib/appname/foo, /var/lib/appname/bar,…
Init script устанавливает переменную окружения PYTHONPATH=/var/lib/appname
После этого import foo, import bar просто работают.
И зачем здесь virtualenv?
пока вы не понимаете нафик вам virtualenv — не используйте его. Это ок =)
я не уверен что от virtualenv много толку в продакшне. Но уверен что в нём дофига толку во время разработки. Имхо.
я не уверен что от virtualenv много толку в продакшне. Но уверен что в нём дофига толку во время разработки. Имхо.
Может Вы найдете полезным для себя в разработке
использовать вот это orchardup.github.io/fig/
использовать вот это orchardup.github.io/fig/
Я Гентушник, брат.
В своей работе я использую всёёёё :-D
Иногда удобен virtualenv, иногда удобен крохотный шелловский самописный скрипт, иногда ты придумываешть нечто своё чуть более громоздкое, чтобы тестовое окружение было ближе к реалиям продакшна…
Однако у virtualenv отнять не одного — это популярен, а потому я крайне редко натыкаюсь на pip install SOMETHING, при SOMETHING не работающим нормально под virtualenv и это определённо плюс.
В своей работе я использую всёёёё :-D
Иногда удобен virtualenv, иногда удобен крохотный шелловский самописный скрипт, иногда ты придумываешть нечто своё чуть более громоздкое, чтобы тестовое окружение было ближе к реалиям продакшна…
Однако у virtualenv отнять не одного — это популярен, а потому я крайне редко натыкаюсь на pip install SOMETHING, при SOMETHING не работающим нормально под virtualenv и это определённо плюс.
>Но если вдруг речь пойдет о Python 2.8
А такой вариант развития событий в принципе рассматривается?
А такой вариант развития событий в принципе рассматривается?
Хм, в оригинале скорее подразумевалось «если бы вдруг речь пошла про Python 2.8». Поправил.
Гвидо вроде бы говорил что 2.8 никогда не будет: www.python.org/dev/peps/pep-0404/
Sign up to leave a comment.
Python на колёсах