Python *

Тихо и незаметно вышла ноль-первая версия библиотеки Pyrant, т.е. Pythonic Tyrant.

Pyrant — это полноценная питонья обвязка для Tokyo Tyrant, сетевого интерфейса для Tokyo Cabinet.

Tokyo Cabinet — это современное, легкое, гибкое и суперское хранилище данных (DBM). Оно поддерживает несколько типов БД, включая как простейшее key/value, так и «табличное», а вернее — документо-ориентированное. Последнее ставит Tokyo в один ряд с такими славными продуктами как CouchDB, MongoDB и др., при этом TC/TT значительно проще и легче, а поэтому быстрее. Кроме того, он поддерживает достаточно сложные запросы по данным (см. список операторов) с различением строчных и числовых значений. И еще для Tokyo Cabinet можно писать расширения на Lua.

Сегодня я расскажу, как построить плагиновую архитектуру в python на include'ах.

Что было нового в версии 3.0:

1. Поддержка питона 3.1 и выше.
2. Опции «process-group», «application-group», «callable-object» и «pass-authorization» могут быть размещены в директивах WSGIScriptAlias и WSGIScriptAliasMatch
3. Если клиент обрывает соединение в процессе обработки итератора вместо «бросания исключения» теперь записывается отладочное сообщение в лог
4. В директиву WSGIDaemonProcess добавлена опция «chroot», позволяющая запускать приложения более изолированно
5. Добавлена глобальная директива WSGIPy3kWarningFlag, при использовании python2.6 будут выдаваться предупреждения
6. Исправлена «assertion error» если питон был скомпилирован с директивой Py_DEBUG
7. Добавлена поддержка «Content-Type: chunked» в запросе (директива «WSGIChunkedRequest»). Данные склеиваются и передаются приложению на обработку.
8. Значения HTTP заголовков теперь передаются в справочнике окружения, для хуков доступа, авторизации и аутентификации
9. Флаг «flag wsgi.run_once» не выставляется в True, при работе в режиме демона, когда «maximum-requests» установлен в 1. В случае использования множества потоков, параметр «maximum-requests» проверяется только после завершения обработки запроса, поэтому нет гарантии, был ли выполнен только один запрос
10. Теперь интерпретаор инициализируется не в родительском процессе, а только после того, как будет создан дочерний
11. Сообщения из модулей-расширений на C попадают в логи виртуальных хостов, как и положено, а не в общий лог, как было ранее
12. Теперь невозможно писать сообщения в логи «чужих» виртуальных хостов
13. В режиме демона может производиться внутренняя переадресация с использоваением заголовка «Location» в ответе
14. В режиме демона может использоваться директива «WSGIErrorOverride», для того, чтобы возвращать стандартные страница ошибок Apache
15. Добавлена директива «WSGIPythonWarnings» работающая по аналогии с директивой «-W» интерпретатора
16. В директиву «WSGIDaemonProcess» добавлена опция «cpu-time-limit» определяющая количество процессорного времени, после которого процесс будет перезапущен
17. В директиву «WSGIDaemonProcess» добавлена опция «cpu-priority» говорящая за себя
18. Добавлена директива «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

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

В Питоне совсем не важно, что вы поместите в определение класса. Это могут быть строки, числа, объекты, переменные. В третьем Питоне можно даже передавать именованные аргументы.

      Осенью вышла книга Марка Пилгрима «Dive into Python 3», и я решил попробовать её перевести на русский язык.
      Собственно, вся работа ведётся в Викитеке — ru.wikisource.org/wiki/Погружение_в_Python_3_(Пилгрим).
      Пока переведено только несколько первых глав, потому что занимаюсь этим я один.

Предисловие

Данную статью я затеял написать после учащающихся вопросов как на форуме так и вопросов в icq на тему многопоточности в CPython. Проблема людей, которые их задают происходит, в основном, из незнания или непонимания основных принципов работы многопоточных приложений. По крайней мере, это относится к используемой мной модели многопоточности, которая носит название Thread Pool (Пул потоков). Часто встречаемой проблемой является и другое: люди не имеют элементарных навыков работы со стандартными модулями CPython. В статья я постараюсь привести примеры такого незнания, не останавливаясь на личностях, так как это по моему скромному мнению неважно. Исходя из условий, в которых пишется эта статья, то мы немного затронем и работу через proxy серверы (не путать с SOCKS).

Преамбула

В связи с выходными потратил немного времени на реализацию сервера Memcache с использованием python-фреймворка Twisted. В итоге я получил быстродействие в два раза более низкое, что я не считаю очень критичным, а также возможность реализовать парочку расширений оригинального протокола. Также возможны оптимизации, которые еще улучшат быстродействие.
Протокол не был реализован полностью — есть еще моменты над которыми можно поработать, но стандартные set/get вполне работоспособны и готовы к использованию.

Средства

Для хранения кеша используем базовый класс dict. Как вы догадываетесь, реализация dict в python быстра, этот базовый тип используется в python настолько активно, что его не оставили без детальной оптимизации. Таким образом, мы автоматом имеем структуру для хранения кеша в памяти. Осталось реализовать протокол memcache, для предоставления доступа к dict другим программам.

Для реализации сервера используем Twisted. Есть множество вариаций неблокирующего IO для python на сегодня, но Twisted это уже классика, и имеет в своем арсенале достаточно средств для легкого решения подобных задач.

Целью статьи является демонстрация возможностей Python for s60 для работы с смс сообщениями и базами данных. Чтобы было интересней, разберем на реальном примере, создадим приложение, которое будет читать новые сообщения смартфона, парсить их, сохранять в свою базу данных номера телефонов с логинами и паролями, и постить твиты, пришедшие с этих номеров.

Для чего это еще может пригодиться? В наше время смс сервисы используются достаточно широко. Способов их реализации достаточно много. У меня недавно возникла необходимость реализовать сервис, при котором клиенты могли бы посылать смс сообщением номер заказа и в ответ приходил бы его статус. Задача решилась так: за 500 руб., на барахолке был куплен старенький Nokia 7610 в разваливающемся состоянии, у которого не работала половина кнопок, были проблемы со звуком и т. д. Туда была вставлена сим карта от местного оператора с безлимитным смс пакетом. Теперь этот аппарат будет играть роль сервера, который будет работать в режиме 24/7, с бесперебойным источником питания (аккамулятор), и не будет знать проблем с охлаждением :)

После того, как мы разогрели аппетит к Python for s60 и начали учиться писать приложения, хочу предложить продолжить постигать программирование для symbain на замечательном языке программирования python.

На этот раз сделаем что нибудь полезное, а именно напишем приложение, которое будет показывать карму. Не просто показывать, а выводить поверх всех «окон» табличку, на которой будет значение кармы и разница с предыдущем значением. Помимо этого, программу будет издавать победный гонг при повышении кармы и крик отчаяния при ее понижении. Ко всему прочему, мы запустим ее, как сервер, то есть она не будет отображаться в списке запущенных программ.

Тем, кому больше важен результат, нежели процесс, милости просим в конец статьи, где вас ожидает готовое приложения HabraKarma 1.0 !!!

По просьбам хабраюзеров я сделал перевод текста, составленного abchernin на основе PEP 8 — «Styleguide for Python Code» (см. топик).

Некоторые фразы я переводить не стал, потому что они к сути дела не относятся, но содержат в себе забавную игру слов.

Надеюсь, вам будет полезна моя работа: pdf, 200кб

Плазмоид (plasmoid) — это виджет рабочего стола в KDE4 Desktop. Любой видимый элемент управления на рабочем столе является плазмоидом, будь то часы, системный трей, монитор загруженности процессора или окошко с прогнозом погоды.

Этот урок описывает создание плазмоида, умеющего делать запросы к некоему серверу и показывать полученный результат. Так как сервер требует авторизации пользователя, будет разобран процесс хранения данных учетной записи пользователя в KWallet. Язык разработки: Python.

Краткий перевод обсуждения Recommendation against Python?:

kng
Я слышал, что сотрудникам Google не рекомендуют использовать Python для новых проектов, что мне кажется глупым, учитывая как много питоновского кода и поддержки самого языка Python исходит из Google. Я начал поиски информации, но ничего не нашел. Вы знаете что-то об этом или это просто слухи?

Collin Winder
Даже простой здравый смысл ограничивает применимость Python, когда речь идет о масшабах Google — он не так быстр как Java или C++, работа с тредами хромает, расходуется больше памяти и т.д. Одно из требований, с которым мы сталкиваемся при проектировании новых систем, это «Что мы будем делать, если нагрузка возрастет в 10 или в 100 раз? Что мы будем делать, если целая планета решит что наш новых сервис офигителен?» Любая технология, которая усложняет соблюдение этого требования — и я считаю, что Python попадает в эту категорию — должна быть отвергнута и даже прочие её полезности не играют важной роли в этом случае. Приходится балансировать слабые и сильные стороны Python — ваши разработчики могут быть более продуктивными, используя Python, но если им придется крепко поработать над масштабированием под большую нагрузку, то удастся ли вам вырваться с Python вперед? И т.д.
…
Unladen Swallow планирует сместить этот баланс — чтобы сделать возможным использовать Python в большем числе проектов, где сейчас его использовать еще нерационально. Но панацеей это не будет. Python все еще будет медленнее, чем C или Java, будет использовать больше памяти и ужасно работать с тредами, пока кто-нибудь не решит инвестировать ресурсы в Python в объеме, сравнимом с ресурсами, которые Sun инвестировала в JVM. Я надеюсь, что внимание к производительности Python со стороны разработчиков будет носить лавинообразный характер — чем больше компаний будет заинтересовано в этом, тем больше ресурсов будет инвестировано, тем больше аспирантов будут работать над Python (и выкладывать результаты своей работы) и т.д.

Так получилось, что на хабре принято подсвечивать код с помощью Source Code Highlighter. Список поддерживаемых языков не впечатляет, да и возможности выбрать цветовую схему я не нашел. Существует библиотека pygments, которая понимает большинство используемых языков, умеет выдавать на выходе html, картинки, latex и не только. Но для хабры, как известно, нужен особый подход, и html вывод pygments хабра не пропускает. В связи с этим я написал небольшой класс для pygments, который исправляет это досадное недоразумение. Воспользоваться веб-версией можно по адресу paste.ly.

Добро пожаловать!

    В прошлый раз мы обсуждали, как можно писать свое PyQt4-приложение, опираясь на логику сгенерированного программкой pyuic4 файла. Как это часто бывает — после написания топик получил много интересных и, что самое главное, содержательных комментариев, объясняющих, почему в отдельных случаях я прав, а в других неправ.
    Самое любопытное состоит еще и в том, что обсуждение интересно как для питонистов, так и для приверженцев C++, ибо в данном случае разница невелика, в основном только незначительные вещи в синтаксисе. Все это потому, что PyQt4, по своей сути, является простой оберткой вокруг сишных Qt-классов, сохраняющей все названия и методы. Итак, вот вам чашечка чая или кофе, устраивайтесь поудобнее, давайте начнем нашу беседу.

Небольшое вступление

    Собственно, тогда, давно, я решил попробовать Qt, потому что часто слышал об удобстве разработки под него и своими глазами видел, какая шикарная документация представлена на сайте производителя. Не могу сказать, что это далось легко (я раньше немного писал на GTK), особенно путался в этих бесконечных классах на "Q", но постепенно начало нравиться все больше и больше. В частности потому, что есть отличная привязка к нему для языка Python, на котором я, собственно, в основном и пишу.
    Еще почему? Ну, я мог бы рассказать и о том, что он работает как на почти всех настольных системах, так и на многих мобильных, рассказать про совершенно гениальную объектную систему виджетов и т. п. Но — зачем? Не люблю холивары с приверженцами других визуальных библиотек :) Поэтому давайте считать этот топик чем-то вроде дележки опытом и рассуждений на тему.

В предыдущем посте , я описывал создание простейшего апплета панели Gnome. В этом посте хотелось бы продемонстрировать апплет взаимодействующий с видеопроигрывателем Totem. Данный апплет будет представлять из себя небольшое приложение с 4 кнопками и надписью, у кнопок будет следующая функцианальность: воспроизведение, паузу, воспроизведение предыдущего и следующего.

Четыре года назад, устроившись на новое место работы, увидел учетную систему приличных размеров на python + wxWidgets + MSSql. Весь исходный код генерировался автоматически на основе UML диаграмм. Спустя несколько лет, я настолько проникся таким способом разработки, что и в собственных проектах на Django стал использовать автогенерацию кода.
Давайте в общих чертах рассмотрим, как выглядит процесс создания «кодогенерируемого» проекта?

Тихо и незаметно зарелизился django-jython версии 1.0.0 — замечателная разработка,
которая позволяет развёртывать приложения django на java серверах приложений.

Сегодня я хочу рассказать вам, как я настраивал любимый всеми редактор Vim (который в одном режиме пищит, а в другом — все портит) для написания кода на Python. Статья расчитана на начинающих виммеров.
У меня получилась такая картинка: