Python *

Хабр — не для политики. В данной статье рассматриваются исключительно технические аспекты реализации конкретного программного решения. Для всеобщего блага просьба отказаться от каких-либо политических дебатов, выступлений, агитации и тому подобных действий в комментариях. Кроме того, просьба не применять полученные знания в деструктивных целях, не начинать бекапить весь видеоархив без особой надобности и так далее. Спасибо.

8 сентября, единый день голосования. В этом году широкой общественности предлагается наблюдать через интернет за выборами столичного мэра. Ряд граждан считают для себя интересным записать картинку с камер: у кого-то политически мотивированный интерес, а большинству просто банально любопытно посмотреть на себя и знакомых глазами Интернета. Данная статья призвана продемонстировать принципы работы текущей системы и предложить работающие концепты.

Только ленивый ещё не писал о необходимости писать тесты. Но давайте признаемся честно — писать тесты зачастую скучно. Особенно для legacy-кода. Сотни повторяющихся, однообразных строк. Скука. Что с этим можно сделать?


^{Картинка для привлечения внимания. Красивый питон, да? (Автор фото: Paweł Stefaniak)}

Многие знакомы с выступлением Алекса Мартелли (Alex Martelli) на Google Tech Talk под названием Python for Programmers (слайды) — в нём он чётко и лаконично рассказывает основы Питона для тех, кто уже умеет программировать, например на C, С++ или Java. По его презентации я сам учил Питон четыре года назад, перед тем как начать использовать его в преподавании программирования на матмехе СПбГУ.

Сегодня хочу представить вам интерактивный вариант этой презентации — онлайн мини-курс Python for Programmers, созданный и опубликованный под лицензией Creative Commons с разрешения Алекса. Мы добавили к его презентации интерактивных упражнений, обновили материал с Python 2.5 до Python 3.3, добавили информацию по актуальным библиотекам и разнице между 2 и 3 версиями Питона.

Когда я работал над своей магистерской диссертацией, я пообещал себе, что опубликую ее в Интернете под свободной лицензией. Я получил степень, но, к сожалению, натолкнулся на одно из неписаных правил ВУЗов — когда вы тратите на интересующий вопрос много времени, он вам надоедает.
Наконец, спустя год, я все-таки ее публикую.
Для тех, кому лень знакомиться с моим полным трудом (в любом случае, 60 страниц текста это не так много для исследовательской работы, но это все же не мало), я предлагаю краткую версию статьи. Прошу заметить, что краткая версия не учитывает некоторые важные сведения, поэтому я прошу писать отзывы только о полной версии.

В своём исследовании я обратил внимание на доводы сторонников динамической типизации, которые считают, что статическая типизация не нужна для выявления ошибок.

Суть их рассуждений в следующем:

1. Статической типизации недостаточно для выявления багов, поэтому необходимы модульные тесты;
2. Статическая типизация становится лишней, так как у вас есть тесты;
3. Из-за статической типизации некоторые корректные программы могут выдавать предупреждения на стадии компиляции.

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

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Продолжаем перевод цикла статей о внутренностях Питона. Если вы хоть раз задавались вопросом «а как же оно устроено?», обязательно читайте. Автор проливает свет на многие интересные и важные аспекты устройства языка.

В предыдущих частях мы говорили об объектной системе Питона. Тема ещё не исчерпана, но давайте пойдём дальше.

Когда я размышляю о реализации Питона, я представляю себе огромный конвейер, по которому движутся коды машинных операций, которые затем попадают в гигантский завод, где повсюду возвышаются градирни и башенные краны, — и меня просто переполняет желание подойти поближе. В этой части мы поговорим о структурах состояния интерпретатора и состояния потока (./Python/pystate.c). Сейчас нам нужно заложить фундамент, чтобы потом было легче понять, как исполняется байткод. Совсем скоро мы узнаем, как устроены фреймы, пространства имён и объекты кода. Но для начала давайте поговорим о тех структурах данных, которые связывают всё воедино. Учтите, я предполагаю наличие хотя бы поверхностного понимания устройства операционных систем и знания хотя бы таких терминов, как ядро, процесс, поток и т. п.

Во многих операционных системах пользовательский код исполняется в потоках, которые живут в процессах (это верно для большинства *nix-систем и для «современных» версий Windows). Ядро ответственно за подготовку и удаление процессов и потоков, а также за определение того, какой поток на каком логическом CPU будет исполняться. Когда процесс вызывает функцию Py_Initialize, на сцену выходит другая абстракция, интерпретатор. Любой Python-код, запускаемый в процессе, привязан к интерпретатору. Об интерпретаторе можно думать как об основе всех прочих концепций, которые мы будем обсуждать. Питон поддерживает инициализацию двух (и более) интерпретаторов в одном процессе. Несмотря на то, что эта возможность редко используется на практике, я буду её учитывать. Как было сказано, код исполняется в потоке (или потоках). Не исключение и виртуальная машина Питона (VM). При этом сама VM имеет поддержку потоков, т.е. у Питона есть своя абстракция для представления потоков. Реализация этой абстракции полностью полагается на механизмы ядра. Таким образом, и ядро, и Питон имеют представление о каждом из Python-потоков. Эти потоки управляются ядром и исполняются как отдельные потоки параллельно всем прочим потокам в системе. Ну… почти параллельно.

До сих пор мы не обращали внимания на слона в нашей посудной лавке.

Достаточно давно мне на глаза попались следующие статьи по этой тематике:

• nginx, memcached и SSI
• Nginx + Memcached + SSI — кеширование страниц и блоков (partials)
• Кеширование страниц — ускоряем сайт в 100 раз (Varnish + ESI)

С PHP я дружу, поэтому попробовал примеры и убедился, что это работает. Но всё это имело «фатальные недостатки» :) — PHP, а я фанат Python и по работе занимаюсь в основном бэкендом. Серьёзно говоря, применить на практике это не представлялось возможным.

Однако в начале года поступило предложение поучаствовать в одном амбициозном проекте, изначально подразумевающий HiLoad и прочие плюшки из этой оперы. Пока составлялись бизнес-планы, искались инвесторы и тому подобные дела, я решил изучит вопросы которые на мой взгляд пригодились бы в этой работе, в том числе и вопросы кэширования.

В первую очередь было реализовано черновое решение для моего любимого фрэймворка Flask использующее для кэширования стек Varnish+ESI. Это заработало и даже показало неплохие результаты. Позже пришло понимание, что возможно Varnish «лишний игрок» и всё тоже и даже гибче можно получить на связке Nginx+Memcached+SSI. Был сделан и этот вариант, по производительности особых отличий замечено не было, но последний показался более гибким и управляемым.

Тот проект не вырулил даже на взлетную полосу, или вырулил но без меня. Подумав, я решил «причесать код» и выложить его в OpenSource и на суд общественности.

Обработка ошибок в Go построена не на закостенелом механизме исключений, а на новом интересном механизме отложенных обработчиков. В качестве интересного исследования я реализовал такую обработку ошибок на Python. Кому интересно, заходите.

Время было вечером, делать было нечего… Было решено удивить хабражителей. Но как? Банальные поиски уязвимостей на известных сайтах уже никому не интересны. Чтож, значит включим фантазию… Ведь у пользователей тоже есть сайты! Срочно проверить их на стойкость!

Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.

Что такое PLY?

PLY — это аббревиатура из первых букв выражения: Python Lex-Yacc.
Фактически, это порт утилит lex и yacc на python в красивой обертке.
Работать с ply очень просто и порог входа для начала использования практически нулевой.
Написан он на чистом питоне и представляет из себя LALR(1) парсер, но кому это интересно?
Я по натуре практик (как и большинсво из вас) поэтому пошли в бой!

Что будем делать?

На сайте есть пример написания очередного калькулятора, поэтому повторяться не будем. А сделаем что-то навроде парсера очень очень узкого подмножества PHP :)
Наша задача в конце статьи построить синтаксическое дерево для такого примера:

<?php
$val = 5;
$result = substr( "foobar", 2*(7-$val) );
echo "это наш результат: $result";

Пример очень маленький и взят с потолка. Но чтобы построить дерево кода нужно много и походу мы задействуем такой механизм PLY как state.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

В предыдущей части мы начали изучение объектной системы Питона: поняли, что именно можно считать объектом и каким образом объекты выполняют свою работу. Продолжим рассмотрение вопроса.

Приветствую вас в третьей части нашего цикла статей о внутренностях Питона (строго рекомендую прочитать вторую часть, если вы этого ещё не сделали, иначе ничего не поймёте). В этом эпизоде мы поговорим о важном понятии, к которому всё никак не подберёмся, — об атрибутах. Если вы хоть что-нибудь писали на Питоне, то вам доводилось пользоваться ими. Атрибуты объекта — это другие, связанные с ним, объекты, доступные через оперетор . (точка), например: >>> my_object.attribute_name. Кратко опишем поведение Питона при обращении к атрибутам. Это поведение зависит от типа объекта, доступного по атрибуту (уже поняли, что это относится ко всем операциям, связанным с объектами?).

В типе можно описать специальные методы, модифицирующие доступ к атрибутам его экземпляров. Эти методы описаны здесь (как мы уже знаем, они будут связаны с необходимыми слотами типа функцией fixup_slot_dispatchers, где создаётся тип… вы же прочитали предыдущий пост, так ведь?). Эти методы могут делать всё, что угодно; описываете ли вы свой тип на C или на Python, вы можете написать такие методы, которые сохраняют и возвращают атрибуты из какого-нибудь невероятного хранилища, если вам так угодно, вы можете передавать и получать атрибуты по радио с МКС или даже хранить их в реляционной базе данных. Но в более-менее обычных условиях эти методы просто записывают атрибут в виде пары ключ-значение (имя атрибута/значение атрибута) в каком-нибудь словаре объекта, когда атрибут устанавливается, и возвращают атрибут из этого словаря, когда он запрашивается (или выбрасывается исключение AttributeError, если в словаре нет ключа, соответствующего имени запрашиваемого атрибута). Это всё так просто и прекрасно, спасибо за внимание, на этом, пожалуй, закончим.

Стоять! Друзья мои, фекальные массы ещё только начали своё стремительное приближение к вращающемуся ветрогенератору. Пропадать, так всем пропадать. Предлагаю совместно изучить, что происходит в интерпретаторе, и задать, как мы обычно делаем, несколько раздражающих вопросов.

Некоторое время назад я писал о замечательном продукте: Salt.

Время не стоит на месте, и Salt тоже развивается.

Из последних изменений могу отметить:
— Попытка монетизации проекта (Проект переехал на .com и обзавелся платной поддержкой)
— Over States
— Node Groups
— Очень много нового в документации
— Субъективно более качественная поддержка windows

Пост обещает быть сверхкратким.

ExConsole позволяет встроить интерактивную консоль-отладчик в Python-приложение. Консоль вызывается при фатальном исключении либо по приему SIGQUIT (он же Ctrl-\).

Пример использования:

import exconsole
exconsole.register()

do_dangerous_stuff()

Пример работы с консолью:

Activating emergency console
----------------------------
Caused by:
ZeroDivisionError
integer division or modulo by zero

Stack frames:
  [  0] example.py:17

  [  1] example.py:15
              Tester().test()
  [  2] example.py:9
                  self.inner()
  [  3] example.py:6
                  self.divide(2, 0)
> [  4] example.py:3
                  return a / b
On frame 4
Source:
           def divide(self, a, b):
    >>         return a / b

Press Ctrl-D to leave console
Type "_help()"" for built-in commands

>>> print a,b
2 0
>>> _f(3)
On frame 3
Source:
           def inner(self):
    >>         self.divide(2, 0)

>>> print self
<__main__.Tester instance at 0x7f67c9a0e440>

Захотелось продолжить серию постов о всяких интересных автореферентных штуковинах и решил я написать о жанре Zoomquilt. Сделал поиск, увидел, что один пост на Хабре уже есть. Подумал, подумал и решил, что пост я всё равно напишу, но он будет технический, о технологии создания Zoomquilt.

Для начала собственно о жанре. Тут проще показать чем рассказывать.

zoomquilt.org

zoomquilt2.madmindworx.com/zoomquilt2.swf

www.syfy.com/tinman/oz

www.deviantart.com/art/kopfsalat-digital-edition-30069104

Приближаемся к картинке и вместо того, чтобы в какой-то момент увидеть пиксели величиной с кулак, видим следующую картинку, повторяем процедуру многократно (на самом деле, выглядит это как один вполне себе плавный процесс и если художники хорошо поработали, то «стыков» мы вообще не увидим) и в итоге приходим к первоначальной картинке. В общем мультиквайны, только для художников.
А как такая штука делается? Конечно можно нарисовать это всё покадрово, более того, некоторые талантливые аниматоры вполне бы с этим справились. Но практически во всех существующих произведениях этого жанра указано, что это плоды коллективного творчества. Обычно есть коллектив художников, координатор проекта и программист, который собственно собирает это всё вместе и пишет интерфейс.

Дальше о технологии создания. Под катом много картинок.

Предисловие:

В Беларуси стоит острая проблема с получением виз в Еврозону (т.е. Шенген). Все из-за того, что Польское посольство предоставляет так называемые мульти-визы за покупками (т.е. многократные). Регистрация производится на сайте посольства онлайн. Но вся проблема состоит в том, что свободных дат не словить. Единственный вариант — круглосуточно чекать страницу, и если появится дата — быстро «ловить» ее и заканчивать регистрацию. Т.к. свободного времени для круглосуточного чека нет, было принято решение об автоматизации данного процесса.
Сразу оговорюсь, что существуют различные скрипты, которые вылавливают свободные даты и за которые люди получают деньги. Мой скрипт не претендует на их место по быстроте, качеству и т.д. Данный скрипт был сделан только для себя, никакой коммерческой и иной выгоды я не преследовал.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Продолжаем разбираться во внутренностях Питона. В прошлый раз мы узнали, как Питон переваривает простую программу. Сегодня начнём изучение устройства его объектной системы.

Как я и писал в предыдущем эпизоде (который, кстати, оказался успешным; спасибо всем, ваши просмотры и комментарии буквально заставляют меня двигаться дальше!) – сегодняшний пост посвящён реализации объектов в Python 3.x. Поначалу я думал, что это простая тема. Но даже когда я прочитал весь код, который нужно было прочитать перед тем, как написать пост, я с трудом могу сказать, что объектная система Питона… гхм, «простая» (и точно не могу сказать, что до конца разобрался в ней). Но я ещё больше убедился, что реализация объектов — хорошая тема для начала. В следующих постах мы увидим, насколько она важна. В то же время, я подозреваю, мало кто, даже среди ветеранов Питона, в полной мере в ней разбирается. Объекты слабо связаны со всем остальным Питоном (при написании поста я мало заглядывал в ./Python и больше изучал ./Objects и ./Include). Мне показалось проще рассматривать реализацию объектов так, будто она вообще не связана со всем остальным. Так, будто это универсальный API на языке C для создания объектных подсистем. Возможно, вам тоже будет проще мыслить таким образом: запомните, всё это всего лишь набор структур и функций для управления этими структурами.

Теперь если Вас просят показать, как что-то выполняется в консоли, не надо копировать вывод из putty или записывать видео через snagIt. Утилита ascii.io сделает все это за Вас.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Помимо изучения стандартной библиотеки, всегда интересно, а иногда и полезно, знать, как язык устроен изнутри. Андрей Светлов (svetlov), один из разработчиков Python, советует всем интересующимся серию статей об устройстве CPython. Представляю вам перевод первого эпизода.

Мой друг однажды сказал мне: «Знаешь, для некоторых людей язык C — это просто набор макросов, который разворачивается в ассемблерные инструкции». Это было давно (для всезнаек: да, ещё до появления LLVM), но эти слова хорошо мне запомнились. Может быть, когда Керниган и Ритчи смотрят на C-программу, они на самом деле видят ассемблерный код? А Тим Бёрнерс-Ли? Может он сёрфит интернет по-другому, не так, как мы? И что, в конце концов, Киану Ривз видел в том жутком зелёном месиве? Нет, правда, что, чёрт побери, он там видел?! Эм… вернёмся к программам. Что видит Гвидо ван Россум, когда читает программы на Python?

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



Изначально автоматизация заключалась в банальном Excel-файле, в котором были «забиты» соответствующие формулы. Но потом было решено написать небольшую программу. Причем это преследовало сразу две цели — получить более удобный «продукт» и наконец-то написать что-то действительно полезное на Python, который мне давно нравится. Правда знания мои в этой области весьма и весьма скромные, но тем задача интереснее.

Мы в Буруках любим не только людей и цифры. Мы также без устали совершенствуемся во владении нашим основным инструментом, языком Python. Ссылка для тех, кто хочет совершенствоваться с нами. В этой статье-переводе автор разбирает устройство namedtuple и по ходу рассказывает об одной из основных концепций языка.

Пару дней назад я был на пути в Сан-Франциско. Интернета в самолёте не было, поэтому я читал исходники стандартной библиотеки Python 2.7. Реализация namedtuple показалась мне особенно интересной, наверное, потому, что на деле всё гораздо проще, чем я думал раньше.

Вот здесь лежат исходники. Если вы никогда раньше не знали о namedtuple, то рекомендую ознакомиться с этой функцией.