Python *

Данная статья не является продолжением повествования об обёртках C++ API. Никаких обёрток сегодня не будет. Хотя по логике это третья часть данного повествования.
Сегодня будет море крови, расчленение существующих типов и магическое превращение их в привычные аналоги в другом языке.
Речь не пойдёт о существующей конвертации между строками, нет, мы напишем свои конвертеры.
Мы превратим привычный datetime.datetime питона в boost::posix_time::ptime библиотеки Boost и обратно, да чёрт с ним, мы вообще всю библиотеку datetime превратим в бустовые типы! А чтобы не было скучно, принесём в жертву встроенный класс массива байт Python 3.x, для него как раз ещё нет конвертера в Boost.Python, а потом зверски используем конвертацию массива байт в новом конвертере питоновского uuid.UUID в boost::uuids::uuid. Да, конвертер можно использовать в конвертере!
Жаждешь крови, Колизей?!..

Всем доброго времени суток!
Недавно я задал вопрос на habre, про аналог библиотеки jevix для python.
Мне подсказали решение, но этих решений мне было недостаточно, да и всем известно что Jevix самая популярная библиотека для работы с html.

Для тех кто впервые слышит по Jevix

Jevix — средство автоматического применения правил набора текстов, наделённое способностью унифицировать разметку HTML/XML документов, контролировать перечень допустимых тегов и аттрибутов, предотвращать возможные XSS-атаки в коде документов.

Автором этой библиотеки для php является, хабра житель ur001, ссылка на проект jevix.ru/project

Данная статья является продолжением первой части.
Продолжаем мучить Boost.Python. В этот раз настала очередь класса, который нельзя ни создать, ни скопировать.
Обернём почти обычную сишную структуру с необычным конструктором.
И поработаем с возвращением ссылки на поле объекта C++, так чтобы сборщик мусора Python его не удалил ненароком. Ну и наоборот, сделаем альтернативный вариант, чтобы Python прибрал мусор после удаления того, что ему отдали на хранение.
Поехали…

Понадобилось нам однажды измерять температуру и влажность в одном помещении, несложная задача, стоит обратиться в гугл и там до кучи примеров на ардуино как это сделать, скетчи, схемы и пояснения. Простые задачи подобного рода возникают достаточно часто и каждый раз модифицировать код для контроллера не хотелось. Мы подумали, а что если написать что-то типа интерпретатора для микроконтроллера(МК), который бы принимал команды и выполнял их. Таким образом отпадает необходимость писать софт каждый раз для МК, это занятие требует времени зачастую больше, чем под ПК из-за того, что объем памяти МК ограничен и не попользуешься развитыми средствами типа regex и прочего. Интерпретатор должен быть расширяемый, то есть добавление новой команды, не должно быть зубодробительной операцией. Также в будущем он должен быть легко переносим на ARM Cortex-M3 архитектуру и способен работать через различные интерфейсы связи будь то RS485, Ethernet, ZigBee.

Другие наши проекты здесь

На основании этих требований было решено разработать такое устройство и + библиотеки для работы с ним под несколько языков (сейчас Python и GCC C/C++) и ОС ( Win и Linux) чтобы не париться больше с написанием каждый раз софта для контроллера, который делает рутину — собирает данные или что-то включает или выключает.


Рис. 1. Контроллер MeteoBoard

Эта статья предназначена для новичков. Здесь будет описано как из web приложения при помощи ajax запросов посылать команды phyton скрипту, который будет передавать их через serial port непосредственно на наш arduino.
Вы приобрели себе Arduino, попробовали несколько примеров, поигрались со скетчами. Но вам этого мало, вы хотите управлять, управлять всем этим добром через интернет. Самый простой способ — это приобрести шилдик с Ethernet-портом и подключить его к Arduino (или приобрести платку с уже встроенным Ethernet ). Но она и стоит дороже и в управлении надо поднатаскаться.

Как известно, в основной реализации Питона CPython (python.org) используется Global Interpreter Lock (GIL). Эта штука позволяет одновременно запускать только один питоновский поток — остальные обязаны ждать переключения GIL на них.

Коллега Qualab недавно опубликовал на Хабре бойкую статью, предлагая новаторский подход: создавть по субинтерпретатору Питона на поток операционной системы, получая возможность запускать все наши субинтерпретаторы параллельно. Т.е. GIL как бы уже и не мешает совсем.

Идея свежая, но имеет один существенный недостаток — она не работает…

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

Boost.Python во всех отношениях замечательная библиотека, выполняющая своё предназначение на 5+, хотите ли вы сделать модуль на С++ для Python либо хотите построить скриптовую обвязку на Python для нативного приложения написанного на С++.
Самое сложное в Boost.Python — это обилие тонкостей, поскольку и C++ и Python — два языка изобилующие возможностями, и потому на стыке их приходится учитывать все нюансы: передать объект по ссылке или по значению, отдать в Python копию объекта или существующий класс, преобразовать во внутренний тип Python или в обёртку написанного на C++, как передать конструктор объекта, перегрузить операторы, навесить несуществующие в C++, но нужные в Python методы.
Не обещаю, что в своих примерах опишу все тонкости взаимодействия этих фундаментальных языков, но постараюсь сразу охватить как можно больше частоиспользуемых примеров, чтобы вы не лазили за каждой мелочью в документацию, а увидели все необходимые основы здесь, или хотя бы получили о них базовое представление.

Замечательный PEP8, с которым вы наверняка знакомы, если занимаетесь разработкой на Python, не отвечает на все возникающие в процессе кодинга вопросы. В итоге каждая команда разработчиков берёт PEP8 за основу и вырабатывает собственные стандарты, которых старается придерживаться. Сколько команд – столько вариантов. И это необходимые искусственные рамки. Как сетка для типографа или верстальщика – помогает коду выглядеть чётко, выдержано и последовательно. В общем, форматирование кода – это не то место, где нужно проявлять свою индивидуальность.

Однажды, холодным зимним вечером, я внезапно вспомнил, что не поделился простым секретом, как добиться простого питоновского счастья за пределами ASCII резервации в такой замечательно-бесплатной IDE как Eclipse с плагином PyDev. Причём счастья с отладкой и честным юникодом, что означает следующее: если вы назвали свою переменную кириллицей, вы сможете посмотреть у неё значение, поставив breakpoint, написать пару строк текста по-русски и у вас ничего не отвалится.
Да-да, уважаемый читатель, Eclipse PyDev не очень-то дружит с символами за пределами 0x7F и отладка очень любит отваливаться всякий раз при попытке прочитать значение кириллической переменной. Да какое там, простое наведение мышкой на юникодовый символ приводит к фатальным последствиям при отладке кода написанного на Python 3.x (UTF-8). Если же настройки вашей файловой системы отличаются от UTF-8, поздравляю, вы не сможете даже запустить ваш скрипт. Я имею в виду именно то, что например под Windows ваш замечательный скрипт с единственным словом по-русски просто выведет из строя PyDev.
Возможно я перестарался, сгущая краски, не пугайтесь, починить это в состоянии мы сами, просто прочитав эту небольшую инструкцию. В награду мы получим бесплатное средство разработки, довольно удобное, фантастически гибкое в настройках и усовершенствовании, вплоть до разработки на нескольких языках, со встроенным инструментом версионирования.
Под катом инструкция и неприличных размеров картинки.

Введение.

Python замечательный язык. Связка Python + NumPy + Matplotlib, на мой взгляд, сейчас одна из лучших для научных расчётов и быстрого прототипирования алгоритмов. Но у каждого инструмента есть свои светлые и тёмные стороны. Одной из самых дискутируемых особенностей Python является GIL – Global Interpreter Lock. Я бы отнёс эту особенность к тёмной стороне инструмента. Хотя многие со мной не согласятся.

Если кратко, то GIL не позволяет в одном интерпретаторе Python эффективно использовать больше одного потока. Защитники GIL утверждают, что однопоточные программы при наличии GIL работают намного эффективнее. Но наличие GIL означает, что параллельные вычисления с использованием множества потоков и общей памяти невозможны. А это достаточно сильное ограничения в современном многоядерном мире.

Один из способов преодоления GIL при помощи потоков на C++ был недавно рассмотрен в статье: Использование Python в многопоточном приложении на C++. Я же хочу рассмотреть другой способ преодоления ограничений GIL, основанный на multiprocessing и shared array. На мой взгляд, этот способ позволяет достаточно просто и эффективно использовать процессы и разделяемую память для прозрачного параллельного программирования в стиле множества потоков и общей памяти.

Все более или менее знающие Python разработчики знают про такую жуткую вещь как GIL. Глобальный блокировщик всего процесса до тех пор пока Python выполняется в одном из потоков. Он даёт потоко-защищённость методами сравнимыми с садизмом, поскольку любая неявная блокировка в многопоточном приложении смерти подобна, всё что опиралось на параллельное выполнение, умирает в мучениях, раз за разом натыкаясь на блокировку GIL.
Известно что по сей день из-за этого скорбного факта программисты на C++ используют Python-обёртки по большей части лишь в однопоточных приложениях, а программисты на Python пытаются всех убедить, что им и так неплохо живётся.
Казалось бы, если поток порождён в C++, он не знает ни о каком GIL, используй Python без блокировок и радуйся. Радость разработчика однако закончится уже на втором потоке запросившем область глобальных переменных без блокировки.
Однако есть путь ведущий к светлому будущему!
Этот путь был изначально в таком языке как Perl, он же поддерживается в Си-API языка Python и я ума не приложу почему подобный механизм не включен в один из стандартных модулей Python! Способ по сути сводит использование различных под-интерпретаторов Python в разных потоках, причём используя свой GIL для каждого(!!!) без всякого шаманства и магии, просто последовательно вызвав несколько функций и стандартного набора Си-API языка Python!

… на 90%. Т.е. какие-то подвижки ещё могут быть, шесть человек ещё определяются с докладами, но большая часть содержательной части конференции готова. Предлагаем её вашему вниманию:

По мотивам этого поста.
В прошедшем 2012 году я, как и миллионы других пользователей открыл для себя бесплатное онлайн обучение. Всё началось с прекрасного стартапа Codecademy. Замечательные курсы про JavaScript, jQuery, Python, Ruby и другие занимали всё свободное время. Побочным эффектом стала практика чтения на английском. К середине года доступные уроки закончились и я стал интересоваться другими площадками, где можно продолжить самообучение. Как раз в то время на Хабре участились статьи про Coursera и я решил попробовать.
Первым курсом который привлек внимание был An Introduction to Interactive Programming in Python от Rice University. Недолго думая, я вступил в стройные ряды онлайн студентов.

Начать, видимо, следует с того, что речь пойдет об интерпретаторе CPython версии 2.7.x (примеры проверялись на версии 2.7.3).

На официальном сайте имеются описания инструкции import и модулей в Python:

• docs.python.org/2/reference/simple_stmts.html#import
• docs.python.org/2/tutorial/modules.html

Из них следует, что в Python имеются пакеты (package), модули (module) и имена, определенные в модулях (names). Также следует отметить, что в некоторых частях документации модули называются подмодулями (submodule), если они размещены внутри пакета.

В языке Python инструкция import позволяет импортировать пакеты, модули и имена в пространство имен, в котором инструкция import выполняется. При это существует две интересные особенности:

1. Из синтаксиса инструкции import не всегда явно следует, что именно должно быть импортированно: пакет, модуль или имя
2. Синтаксисом инструкции import невозможно явно указать, что путь к модулю является абсолютным путем (хотя явно указать, что путь является относительным можно, а также возможно изменение семантики инструкции, в части использования абсолютного пути по умолчанию, см. www.python.org/dev/peps/pep-0328 )

Из этих двух особенностей следуют такие неоднозначности для записи import abcd:

1. Импортировать ПАКЕТ abcd, либо импортировать МОДУЛЬ abcd
2. Импортировать пакет/модуль abcd из ТЕКУЩЕГО ПАКЕТА (из пакета того модуля, в котором исполняется import abcd), либо ИЗ ПАКЕТА в соответствии с перечнем каталогов, указанных в sys.path

Еще примеры неоднозначностей:

• from abcd import defg: (импортировать модуль defg из пакета abcd, либо импортировать пакет defg из пакета abcd, либо импортировать имя defg из пакета abcd, либо импортировать имя defg из модуля abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)
• import abcd.defg: (импортировать пакет defg из пакета abcd, импортировать модуль defg из пакета abcd) X (из того же пакета, либо из пакета в соответствии с sys.path)

Для разрешения эти декларативных неоднозначностей должен существовать императивный алгоритм. Такой алгоритм в некотором виде описан в официальной документации Python.

Я живу в большой семье, в которой много компьютеров. Потребность в выходе в сеть интернет для этих компьютеров удовлетворяет роутер компании D-link DIR-615. В web интерфейсе этого устройства есть всегда меня интересовавшая запись обо всех текущих интернет подключениях проходящих через устройство. Глядя на это громадное количество записей, меня всегда тревожило, а чем это мои домочадцы таким жутким занимаются, а не стали ли они жертвами какого либо жуткого ботнета? Все записи в этой таблице подключений оперируют лишь IP адресами компьютеров в локальной сети и в сети интернет. Отбросив этическую сторону вопроса, я расскажу в этой статье свой скрипт-киддивский способ решения проблемы преобразования списка подключений в человекочитаемый вид.

Как заядлый читатель HAD я был заинтересован этим постом, описывающим способ взлома аудиокапчи MintEye. Графическая версия также выглядела довольно интересно, так что я подумал, что будет забавно взломать и её.

Вот один из примеров графической капчи MintEye:

Продолжение рассказа о замечательном кроссплатформенном фрейворке для функционального-тестирования TextTest. Первая часть статьи.

Предлагаю поговорить сегодня о замечательном фреймворке для тестирования TextTest. Это кроссплатформенный инструмент для функционального тестирования с «record-replay» парадигмой. Как следует из названия TextTest пропагандирует довольно необычный на сегодняшний день подход текст-ориентированного тестирования, который позволяет легко и просто писать и читать тесты. Помимо TextTest мы поговорим о StoryText — являющимся строго говоря отдельном инструменте для тестирования GUI, но совместно с TextTest он позволяет делать это гораздо приятнее. Так же упомянем о третьем модуле от автора — CaptureMock.

В комментариях к моему посту про курс 6.002x MITx мне задавали вопрос — пригодилось ли изученное в жизни. И я отвечал — да, конечно, вот тут утром пока зубы чистил, RC-константу посчитал… Но пруфов не было. С тех пор я закончил еще два курса — UC Berkeley CS188.1x Introduction to Artificial Intelligence (открыта регистрация на 18 февраля) и MITx: 6.00x Introduction to Computer Science and Programming. И если после CS188.1x я просто был полон эмоций и не знал, куда бы приткнуть свежеполученные знания (кроме как решить задачу о ходе коня), то после прохождения 6.00x подвернулся случай блеснуть.