Server-side jQuery

jQuery настолько прекрасен, что портируется и на серверные языки, дабы упростить написание всевозможных парсеров. Я использую два порта, pyquery и phpquery, соответственно — для Python и PHP. Весьма облегчают жизнь.

XtraDB и MariaDB

Оказывается, правильные пацаны потихоньку переходят на XtraDB. Как пишет Википедия:

В последнее время из-за излишней закрытости разработки MySQL компанией Sun Microsystems появилось много сторонних (например, от компании Google) патчей с улучшениями производительности и исправлениями ошибок, большинство из которых были включены в форк InnoDB под названием XtraDB, созданный компанией Percona.

Percona была создана в 2006 году для консультирования и поддержки MySQL-пользователей. И основатели её имеют знакомо звучащие имена, как то Peter Zaitsev и Vadim Tkachenko. В общем, наши люди.

Как известно, InnoDB — это лучший движок для таблиц MySQL с нормальной поддержкой транзакций, внешних ключей и т.п. XtraDB, по заявлениям авторов, работает быстрее плюс позволяет осуществлять бэкап таблиц на лету. У InnoDB тоже есть такой инструмент, но он платный, в отличие от XtraDB. Формат таблиц используют они один и тот же, т.е. можно существующую базу пересадить с одного движка на другой без проблем.

А ещё есть форк MySQL под названием MariaDB. Это детище основателя MySQL Michael "Monty" Widenius. Формат БД, API, имена файлов и т.п. полностью совместимы с MySQL. Взамен обещается ускорение и новые фичи. Ну и движок XtraDB включён в комплект вместо InnoDB.

О MySQL в многопоточном Python'е

В проекте возникла необходимость доступа к MySQL из разных потоков (threads). Я внимаааааааааательно прочитал официальную документацию библиотеки для доступа MySQL из Python, и она заявляет, что нельзя использовать одно и то же подключение к БД в разных потоках.

На помощь спешит PySQLPool, в нём есть методы для создания пула подключений к MySQL.

Я использую движок таблиц (table engine) InnoDB с нормальной поддержкой транзакций. Совсем неинтересно каждый раз писать BEGIN TRANSACTION/COMMIT, это ж Python! Должен быть способ! И он нашёлся.

В версии 2.5 добавили оператор with и контекстные менеджеры. Я написал простенький патч, и использование транзакций стало простым и красивым:

q = PySQLPool.getNewQuery(connection)
with q: # внутренние запросы обёрнуты в транзакцию
            q.Query('INSERT INTO peer SET PeerName=%s', (name,))

Есть и маленькая ложка дёгтя в виде заявленного автором бага при работе с транзакциями из нескольких тредов. В общем-то, ко времени релиза нашего проекта либо я исправлю этот баг, либо автор, либо вы. ;)

Сетевое программирование в Python

Нашёл хороший туториал (PDF) на английском про сетевое программирование в Python — чётко изложена сама теория, кое-чего я и сам не знал, и даны хорошие базовые примеры на Python.
На сайте автора есть и другие неплохие туториалы про Python.

UDP-траспорт

В проекте, над которым я работаю, понадобилось использовать асинхронный UDP-траспорт. Как выяснилось, есть в этой задаче несколько подводных камней — о них и пойдёт речь.

Хотелось что-то максимально простое с помощью встроенных в Python средств.

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

Второй способ — пакет asyncore, который как раз для асинхронных сообщений и предназначен. Правда, только для TCP. Создать нужный класс несложно, но есть несколько тонкостей:

class UdpTransport(asyncore.dispatcher, object):
    def __init__(self, addr=None):
        super(UdpTransport, self).__init__()
        self.ignore_log_types = set() # Для вывода дополнительных ошибок в asyncore, подсмотрел в исходниках asyncore :)
        self.create_socket(socket.AF_INET, socket.SOCK_DGRAM)
        # Размер этого буфера очень важен
        # Если входящий пакет будет больше него, остаток отбрасывается
        self.ReadBufferSize = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)
        if addr:
            self.bind(addr) # Единственное отличие серверного сокета в использовании bind()
        
    def handle_close(self):
        self.close()

    def writable(self):
        return False

    def handle_read(self):
        try:
            data, addr = self.recvfrom(self.ReadBufferSize) 
        except socket.error: # Исключение возникает при чтении данных из сокета: когда они заканчиваются, следующая попытка вылетает
            pass
        # обработка данных

    def send(self, msg, toaddr):
        self.socket.sendto(msg, toaddr)

    handle_connect = handle_read # Нарыл где-то на просторах инета
    # Без этого asyncore не работает с UDP, первую порцию данных он интерпретирует как инициализацию подключения

Наследуемся и от object для использования super и отладки с помощью метакласса.

Вот, собственно, и всё, все хитрости прокомментированы в коде. Естественно, нам не требуется connect() для серверных сокетов, а вместо socket.send/recv нужно использовать методы sendto/recvfrom. Сперва я путался, в каких случаях что нужно применять — документация лаконична — но нашёл хороший источник с примерами, это наш родной `man`. ;) Например, `man bind` (или `man 2 bind`, если быть точным) показывает документацию С-шного сетевого API, обёрткой вокруг которого socket, собственно, и является. Если на вашем *nix такой странички нет, нужно установить пакет manpages-dev (в Debian и Ubuntu, по крайней мере).

Мощь Python

Я не так давно читал про метаклассы в Питоне, и тут представился случай их использовать.
Задача: нужно отладить код сетевого приложения, дебаггером по нему не пройдёшь — при пошаговой отладке состояние сокетов теряется. Я решил печатать имя и аргументы каждого вызванного метода сетевых классов. Вариант со вставкой print в каждый метод — это явно не наш метод. :)

Получился вот такой метакласс:

class DebugMetaclass(type):
    '''Вывод вызова каждого метода объекта с параметрами, удобно при отладке
    сетевых приложений. ;)'''
    def __new__(cls, name, bases, attrs):
        cls.last_signature = None
        for elem in attrs:
            if inspect.isfunction(attrs[elem]):
                attrs[elem] = DebugMetaclass.decorator(attrs[elem])
        return super(DebugMetaclass, cls).__new__(cls, name, bases, attrs)
    
    @classmethod
    def decorator(cls, func):
        '''Возвращает обёрнутую функцию.'''
        @wraps(func)
        def wrapper(*args, **kwargs):
            signature = '%s.%s(%s, %s)' % (args[0].__class__.__name__, 
                                           func.__name__, ', '.join([str(a) for a in args]), 
                                           kwargs)
            if cls.last_signature != signature: # Добавлено для подавления повторяющихся сообщений
                print signature
                cls.last_signature = signature
            return func(*args, **kwargs)
        return wrapper

Класс, который будет использовать этот метакласс, должен наследоваться от object. В моём случае выглядит примерно так:

class UdpTransport(asyncore.dispatcher, object):
    __metaclass__ = DebugMetaclass

Сам dispatcher — это old-style class, поэтому я добавляю ещё одного родителя, но если поместить его первым, лезут баги.

Прекрасные материалы о метаклассах, new-style классах и прочей магии Питона есть на Хабре.
Про обёртки, сиречь декораторы, можно почитать в блоге Романа Ворушина.

В поисках утраченных исходников

Сегодня я работал над модульными тестами для своего Python-проекта. Для простоты файлы тестов называю так же, как и файлы тестируемых модулей. Я решил перенести тесты в другой каталог и мимодумно скопировал их в каталог модулей. Исходники модулей, конечно, затёрлись.
"А-а-а-а!!!" — подумал я. К счастью, остались оригинальные *.pyc-файлы — скомпилированный байт-код Python, который, по идее, можно превратить обратно в исходник.
Быстрый поиск выдал замечательный пост на не менее замечательном StackOverflow. Бесплатная утилита UnPyc помогла почти полностью восстановить один из файлов, но споткнулась на другом, с list comprehensions. Тогда я решил воспользоваться онлайн-сервисом DePython, но у него два ограничения:

1. размер файла должен быть меньше 5 КБ;
2. версия Python <= 2.5.

У меня была 2.6. В том же замечательном посте привели программку для конвертирования pyc-файла в версию 2.3 — вся идея в том, чтобы заменить первые 4 байта файла на соответствующие версии Python. Ещё немножко поиска помогло узнать magic-строку для версии 2.5.
К счастью, модулей было всего два :), осталась последняя закавыка — текст на русском раскодировался в виде \xx-последовательностей. Тогда я обернул текст исходников в такой код:

print """
<здесь перекодированный код>
"""

При запуске скрипта в консоли с локалью UTF-8 вывелись строчки с чистым русским текстом. Ура!

Мораль сего такова: будьте внимательны, чаще коммитьте и не отчаивайтесь.