Python → Перевод официальной документации Pyramid
Ну уж совсем тихо и незаметно, начат процесс перевода официальной документации Pyramid.
Напомню, что Pyramid — это веб-фреймворк, продукт недавнего объединения проектов repoze.bfg и Pylons (с продолжением кодовой базы repoze.bfg). Для сомневающихся отмечу, что Pyramid направлен как раз на большую масштабируемость, что по утверждению разработчиков и послужило причиной для выбора кодовой базы. Поддерживаются функционал обоих “предков”, хотя некоторая вынесена в отдельные пакеты (pyramid_beaker, pyramid_zcml, etc).
Сам перевод, пока что, движется медленно и силами всего одного переводчика. Хотелось бы попросить помощи хабра и ощутить приток “свежей крови”. Желающим влиться, помочь открытому сообществу и/или попробовать подтянуть свой английский, добро пожаловать на репозиторий github перевода.
UPD: Теперь для перевода используется сервис http://notabenoid.com/. По интерфейсу translated.by конечно удобнее, но не поддерживает главы. Таким образом весь перевод теперь хранится в одном месте. Если хотите начать перевод файла, то просто создайте новую главу.
Напомню, что Pyramid — это веб-фреймворк, продукт недавнего объединения проектов repoze.bfg и Pylons (с продолжением кодовой базы repoze.bfg). Для сомневающихся отмечу, что Pyramid направлен как раз на большую масштабируемость, что по утверждению разработчиков и послужило причиной для выбора кодовой базы. Поддерживаются функционал обоих “предков”, хотя некоторая вынесена в отдельные пакеты (pyramid_beaker, pyramid_zcml, etc).
Сам перевод, пока что, движется медленно и силами всего одного переводчика. Хотелось бы попросить помощи хабра и ощутить приток “свежей крови”. Желающим влиться, помочь открытому сообществу и/или попробовать подтянуть свой английский, добро пожаловать на репозиторий github перевода.
UPD: Теперь для перевода используется сервис http://notabenoid.com/. По интерфейсу translated.by конечно удобнее, но не поддерживает главы. Таким образом весь перевод теперь хранится в одном месте. Если хотите начать перевод файла, то просто создайте новую главу.
Python → Pylons и repoze.bfg объединяются в проект Pyramid из песочницы
Информация всплыла благодаря бурно развернувшейся дискуссии в в официальной группе проекта. Конкретно стало известно, что:
- веб-фреймворк Pylons, не так давно добравшийся до релиза 1.0, в нынешнем виде прекращает своё развитие. Несмотря на то, что полная поддержка ветки 1.x будет осуществляться на протяжении ещё нескольких лет, никаких архитектурных изменений и новшеств в проект вноситься не будет;
- имя «Pylons» теперь следует связывать с зонтичным брендом «проект «Pylons», который будет охватывать разработку всех технологий, пожелавших примкнуть к сообществу (по похожему пути идёт развитие проектов под зонтом «Pocoo», среди которых можно отдельно отметить WSGI-стек Werkzeug, шаблонный движок Jinja 2 и систему документирования python-проектов Sphinx);
- главной технологией в рамках проекта Pylons на сегодняшний день является веб-фреймворк Pyramid, распространяемый по лицензии, производной от BSD.
Python → Проекты Python в рамках Google Summer of Code — gevent
Уже весна, а это значит… что скоро лето и очередное Google Summer of Code — возможность получить кучу опыта и даже какое-то материальное вознаграждение. Хочу рассказать об одном интересном проекте, которому вы сможете помочь во время летних каникул — gevent.
Python → mod_wsgi 3.1 вышел 25 ноября
Что было нового в версии 3.0:
И ещё множество исправлений и улучшений, о которых можно почитать в оригинале тут: code.google.com/p/modwsgi/wiki/ChangesInVersion0301
Скачать, как обычно можно тут:
code.google.com/p/modwsgi/downloads/list
UPD:
Да, всё работает
./configure --with-python=python3.1 --disable-framework
make && sudo make install
- Поддержка питона 3.1 и выше.
- Опции «process-group», «application-group», «callable-object» и «pass-authorization» могут быть размещены в директивах WSGIscriptAlias и WSGIscriptAliasMatch
- Если клиент обрывает соединение в процессе обработки итератора вместо «бросания исключения» теперь записывается отладочное сообщение в лог
- В директиву WSGIDaemonProcess добавлена опция «chroot», позволяющая запускать приложения более изолированно
- Добавлена глобальная директива WSGIPy3kWarningFlag, при использовании python2.6 будут выдаваться предупреждения
- Исправлена «assertion error» если питон был скомпилирован с директивой Py_DEBUG
- Добавлена поддержка «Content-Type: chunked» в запросе (директива «WSGIChunkedRequest»). Данные склеиваются и передаются приложению на обработку.
- Значения HTTP заголовков теперь передаются в справочнике окружения, для хуков доступа, авторизации и аутентификации
- Флаг «flag wsgi.run_once» не выставляется в True, при работе в режиме демона, когда «maximum-requests» установлен в 1. В случае использования множества потоков, параметр «maximum-requests» проверяется только после завершения обработки запроса, поэтому нет гарантии, был ли выполнен только один запрос
- Теперь интерпретаор инициализируется не в родительском процессе, а только после того, как будет создан дочерний
- Сообщения из модулей-расширений на C попадают в логи виртуальных хостов, как и положено, а не в общий лог, как было ранее
- Теперь невозможно писать сообщения в логи «чужих» виртуальных хостов
- В режиме демона может производиться внутренняя переадресация с использоваением заголовка «Location» в ответе
- В режиме демона может использоваться директива «WSGIErrorOverride», для того, чтобы возвращать стандартные страница ошибок Apache
- Добавлена директива «WSGIPythonWarnings» работающая по аналогии с директивой «-W» интерпретатора
- В директиву «WSGIDaemonProcess» добавлена опция «cpu-time-limit» определяющая количество процессорного времени, после которого процесс будет перезапущен
- В директиву «WSGIDaemonProcess» добавлена опция «cpu-priority» говорящая за себя
- Добавлена директива «WSGIHandlerscript» позволяющая определить скрипт, обрабатывающий определённый тип файлов
И ещё множество исправлений и улучшений, о которых можно почитать в оригинале тут: code.google.com/p/modwsgi/wiki/ChangesInVersion0301
Скачать, как обычно можно тут:
code.google.com/p/modwsgi/downloads/list
UPD:
Да, всё работает
./configure --with-python=python3.1 --disable-framework
make && sudo make install
Python → Еще один гейт fastcgi-wsgi
Для тех кто работает с высоконагруженной вебой предлагается следующая штука:
Из интересных особенностей:
1) воркеры с независимыми интерпретаторами
2) нити в этих воркерах (логику трэд контекстов можно отключать выставив threads=0)
3) все что можно делать за пределами питона, там и делается
4) почти полностью реализован pep333 (исключение составляют устаревшие методы работы с start_response)
5) при очень жестких условиях с быстрой сборкой ответов дает +35% к rps (пруф?)
6) до 500% больше хэллоувордов ;-) (5к хэллоувордов под лин+кора2дура 2.8)
git clone git://myau.su/fastpy.git fastpyИз интересных особенностей:
1) воркеры с независимыми интерпретаторами
2) нити в этих воркерах (логику трэд контекстов можно отключать выставив threads=0)
3) все что можно делать за пределами питона, там и делается
4) почти полностью реализован pep333 (исключение составляют устаревшие методы работы с start_response)
5) при очень жестких условиях с быстрой сборкой ответов дает +35% к rps (пруф?)
6) до 500% больше хэллоувордов ;-) (5к хэллоувордов под лин+кора2дура 2.8)
Python → Сравнение эффективности способов запуска веб-приложений на языке Python
Последнее время в области веб-разработок стал набирать популярность язык программирования Python. Однако, массовому распространение Python мешает проблема эффективного запуска приложений на этом языке. Пока, в большинстве случаев, это удел выделенных или виртуальных серверов. Модульные языки в отличии от монолитного в базовой функциональности php на каждый запрос подгружают как минимум runtime-библиотеку, а как максимум — ещё несколько десятков запрашиваемых пользователем модулей. Поэтому классический подход наподобие mod_php для Python и Perl не очень уместен, а держать приложение постоянно в памяти было дороговато. Но время движется, техника стала мощнее и дешевле, и уже достаточно давно можно спокойно говорить о постоянно запущенных процессах с приложением в рамках массового хостинга.
Время от времени, в сети появляются различные предложения как запустить приложение на Python. Например, недавно хостинг Джино уникально поправил mod_python и предложил хостинг именно с его помощью. Следом за ним, некий хостинг Locum вообще отринул mod_python с его безопасностью (создаётся впечатление, что суть самобытная безопасность — это единственная проблема АйТи на пути к нирване) и провёл победоносное тестирование modwsgi против fastcgi. Комьюнити же, судя по проведённому мною поиску, разрывается между mod_python и FastCGI. Причём, FastCGI обычно имеется ввиду тот, что идёт в поставке Django — flup. Являясь популярным хостингом Python-приложений, мы не смогли пройти мимо и решили внести свою лепту в эту священную войну.
О чём тут
Время от времени, в сети появляются различные предложения как запустить приложение на Python. Например, недавно хостинг Джино уникально поправил mod_python и предложил хостинг именно с его помощью. Следом за ним, некий хостинг Locum вообще отринул mod_python с его безопасностью (создаётся впечатление, что суть самобытная безопасность — это единственная проблема АйТи на пути к нирване) и провёл победоносное тестирование modwsgi против fastcgi. Комьюнити же, судя по проведённому мною поиску, разрывается между mod_python и FastCGI. Причём, FastCGI обычно имеется ввиду тот, что идёт в поставке Django — flup. Являясь популярным хостингом Python-приложений, мы не смогли пройти мимо и решили внести свою лепту в эту священную войну.
Python → Разворачиваем nginx + mod_wsgi на сервере
Здрасти. Долго-долго я присматривался к замечательному фреймворку django, читал книгу, изучал статьи, пробовал писать hello world'ы (со встроенным в джангу сервером это было легко и приятно). А вчера я попробовал настроить от начала до конца боевой сервер, и как оказалось, это не так просто, и мне даже показалось, что будь я моложе и неопытнее, я бы плюнул на это дело. Вот я и решил поделиться с читателями полной инструкцией, снабдив её некоторыми рассуждениями и конфигами. Статья расчитана на начинающих, но будет интересно всем, обещаю.
Django Framework → Используем память разумно. Часть 2. fapws3
В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.
Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.
Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.
Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.
Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.
Django Framework → Используем память разумно, или mod_wsgi на 256 мегабайтах
Какое-то время назад потребовалось перенести проекты с выделенного сервера на VPS. Для этих целей был выбран slicehost. В общем и целом контора нравится и готов её рекомендовать всем.
Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.
Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.
Я пиарюсь → Diphost — хостинг для фанатов Python
В России очень мало хостингов позволяющих без лишних движений устанавливать Python приложения.
Два года назад покинув Петерхост мы (schors и adnull ) не переставали думать о хостинге, работая над проектами с ним не связанными. Мы активно работаем с Python, и вопрос «что делать?» для нас имел один ответ — качественный хостинг для Python приложений.
Хостинг для фанатов Python — DiPHOST
Нам пришлось повозиться: хороший хостинг это не просто возможность запустить приложение, это и грамотная поддержка клиентов, от людей которые что-то понимают не только в хостинге но и в веб-приложениях, удобная панель управления, постоянное развитие сервисов. Очень много вопросов вставало о фундаментальном удобстве использования, при минимальных затратах. И мы сделали это.
За 350-450 рублей в месяц вы получаете полностью администрируемое решение, достаточно залить приложение и уже начать работать.
Если вы еще сомневаетесь — можете взять и попробовать — 7 дней вы можете тестировать наш хостинг в рабочем режиме совершенно бесплатно.
Для фанатов svn/git/bzr/mercurial — вы можете легко развертывать приложение со своего любимого svnserve/github/launchpad/bitbucket — мы поддерживаем все эти VCS.
Но это только начало. Для фанатов rails мы тоже готовим что-то интересное.
Два года назад покинув Петерхост мы (schors и adnull ) не переставали думать о хостинге, работая над проектами с ним не связанными. Мы активно работаем с Python, и вопрос «что делать?» для нас имел один ответ — качественный хостинг для Python приложений.
Хостинг для фанатов Python — DiPHOST
Нам пришлось повозиться: хороший хостинг это не просто возможность запустить приложение, это и грамотная поддержка клиентов, от людей которые что-то понимают не только в хостинге но и в веб-приложениях, удобная панель управления, постоянное развитие сервисов. Очень много вопросов вставало о фундаментальном удобстве использования, при минимальных затратах. И мы сделали это.
За 350-450 рублей в месяц вы получаете полностью администрируемое решение, достаточно залить приложение и уже начать работать.
Если вы еще сомневаетесь — можете взять и попробовать — 7 дней вы можете тестировать наш хостинг в рабочем режиме совершенно бесплатно.
Для фанатов svn/git/bzr/mercurial — вы можете легко развертывать приложение со своего любимого svnserve/github/launchpad/bitbucket — мы поддерживаем все эти VCS.
Но это только начало. Для фанатов rails мы тоже готовим что-то интересное.