Змееводство

Не самый очевидный del

2019-03-12T09:24:00.000+03:00

В Python 3 следующий код

exc = None
try:
    assert False
except Exception as exc:
    pass
print(exc)

даёт ошибку NameError: name 'exc' is not defined. Это, конечно, здорово, что исключение, образующее циклические ссылки, очищается при выходе из except. Не здорово, что при этом удаляется явно присвоенное значение.

Wildcard DNS

2015-06-08T14:16:00.000+03:00

Памятка себе любимому, а то всё время что-нибудь забываю и заново ищу:

*.vcap.me → 127.0.0.1
*.42foo.com → 127.0.0.1, ::1
*.lvh.me → 127.0.0.1
*.localhost.tv → 127.0.0.1, ::1
*.lacolhost.com → 127.0.0.1
*.ip.xip.io → ip
*.ip.nip.io → ip

Кто не в курсе, использования доменных имён по этим шаблонам позволяет вести разработку с виртуальными хостами (поддоменами) локально и делиться ссылками с коллегами без необходимости править (просить править) /etc/hosts или настраивать dnsmasq.

Грязные технологии: миксины моделей SQLAlchemy

2014-12-17T17:48:00.001+03:00

SQLAlchemy позволяет выносить часть определения модели в отдельный базовый класс, который будет потом «подмешиваться» к другим. Очень удобно, когда есть какой-то повторяющийся кусок в большом количестве классов моделей. Но есть один неприятный момент: все поля должны «знать», к какой модели они принадлежат, а для этого нужно копировать объект поля. С первым уровнем SQLAlchemy хорошо справляется, так что с простым Column всё путём, но ведь поля могут содержать ссылки на другие объекты (например, ForeignKey), к которым предъявляются такие же требования. И тут авторы SQLAlchemy пошли самым простым путём: если нельзя сделать автоматически на все случаи жизни, то не пусть делает пользователь вручную. В результате код миксина должен выглядеть примерно так:

class WithParent(object):
    @declared_attr
    def parent_id(cls):
        return Column(ForeignKey(Parent.id))
    @declared_attr
    def parent(cls):
        return relationship(Parent)

По сути обработанные declared_attr свойства решают ту же проблему, которую мы уже решали декоратором return_locals, а именно позволить выполнять код в определении класса несколько раз. Поэтому и решение напрашивается то же, только теперь нам нужно все свойства дополнительно завернуть в задекорированный метод. Понятно, что мы не хотим делать отдельный вызов нашей фабрики на каждый дескриптор, поэтому однажды полученный результат надо закешировать:

def declared_mixin(*args):

    def wrapper(func):
        attrs = weakref.WeakKeyDictionary()
        def create_descriptor(name):
            def get_attr(cls):
                if cls not in attrs:
                    # Call func only once per class
                    attrs[cls] = return_locals(func)()
                return attrs[cls][name]
            get_attr.__name__ = name
            return declared_attr(get_attr)
        dict_ = {name: create_descriptor(name)
                 for name in func.func_code.co_varnames}
        dict_['__doc__'] = func.__doc__
        return type(func.__name__, args, dict_)

    if len(args)==1 and not isinstance(args[0], type):
        # Short form (without args) is used
        func = args[0]
        args = ()
        return wrapper(func)
    else:
        return wrapper

Теперь наш пример миксина выглядит гораздо приятнее:

@declared_mixin
def WithParent():
    parent_id = Column(ForeignKey(Parent.id))
    parent = relationship(Parent)

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

Грязные технологии: фабрика классов на основе функции

2014-12-03T20:32:00.000+03:00

Так уж получилось, что нам часто требуется определять одинаковые (или почти одинаковые) классы моделей SQLAlchemy для разных MetaData ну и, соответственно, с разными базовыми классами. Декларативно. Повсеместный copy-paste быстро надоел. Были мысли создавать второй класс путём копирования, но уж больно сложно получается: не так просто определить, где на какой глубине остановиться, а где заменить ссылки на что-то уже отзеркалированное. Гораздо проще сделать фабрику и создавать столько классов, сколько нужно. В питоне ж это просто:

def create_C(Base):
    class C(Base):
        id = Column(Integer, primary_key=True)
        # …
    return C

Всё хорошо, только вот отступ лишний появляется. Кому-о, может, и мелочь, а нам он сильно не понравился. Неужели нельзя без него? Ну типа класс задекорировать чем-о так, чтобы он в фабрику превратился. Проблема в том, что тело класса выполняется сразу и только один раз, и никакими декораторами это правило не отменить. Ну да, можно отменить: всего-то с байткодом чуть поколдовать. Только уж очень гразным хак получается и переносимость между версиями под большим вопросом.

Зато вот у функции тело можно выполнять когда захочешь и сколько угодно раз. Почему бы этим не воспользоваться и не превратить декоратором функцию в класс?

@create_class(Base)
def C():
    id = Column(Integer, primary_key=True)
    # …
    return locals()

Опять что-то лишнее, теперь return locals(). А в реальных задачах у нас появятся аргументы у функции (пространство имён с другими моделями, например — нам же надо как-то внешние ссылки да связи определять), которыми не захочется пространство имён класса засорять, так что строчка ещё усложнится.

Вот бы здорово было бы вернуть локально определённые переменные автоматически. И это как раз можно сделать. Немного оптимизации (зачем нам держать трейсер весь вызов, это же приличные накладные расходы?), немного уважения к тем, кто это будет потом отлаживать дебаггером или профилировать, и получается такой декоратор:

import sys, functools, inspect


def return_locals(func):
    '''Modifies decorated function to return its locals'''

    @functools.wraps(func)
    def wrap(*args, **kwargs):
        frames = []

        def tracer(frame, event, arg):
            frames.append(frame)
            sys.settrace(old_tracer)
            if old_tracer is not None:
                return old_tracer(frame, event, arg)

        old_tracer = sys.gettrace()
        sys.settrace(tracer)
        try:
            func(*args, **kwargs)
        finally:
            sys.settrace(old_tracer)
        assert len(frames) == 1
        argspec = inspect.getargspec(func)
        argnames = list(argspec.args)
        if argspec.varargs is not None:
            argnames.append(argspec.varargs)
        if argspec.keywords is not None:
            argnames.append(argspec.keywords)
        return {name: value 
                for name, value in frames.pop(0).f_locals.items()
                if name not in argnames}

    return wrap

Осталась мелочь, создать декоратор самой фабрики:

def create_class(*bases):
    def wrapper(func):
        return type(func.__name__, bases, return_locals(func)())
    return wrapper

Shared memory с помощью mmap

2014-05-12T19:43:00.002+04:00

Оказывается, можно использовать mmap() для создания общей памяти между процессами. А если процессы порождаются с помощью fork(), то в mmap() можно передавать -1 в качестве дескриптора:

import mmap
shmem = mmap.mmap(-1, size, mmap.MAP_ANONYMOUS|mmap.MAP_SHARED,
                  mmap.PROT_READ|mmap.PROT_WRITE)

PIL: Конвертация RGBA в RGB

2014-01-23T18:47:00.000+04:00

Не первый раз сталкиваюсь с задачай и каждый раз ищу решение. В этот раз задокументирую:

from PIL import Image

def rgba_to_rgb(image, background='white'):
    assert image.mode=='RGBA'
    bg_image = Image.new('RGB', image.size, background)
    bg_image.paste(image, mask=image.split()[3])
    return bg_image

Automatic filtering in SQLAlchemy: motivation

2012-05-03T19:33:00.000+04:00

Server side code of web project usually has 3 layers:

data classes mapped to relational database,
request handlers for each URL pattern,
templates used to render pages.

Simple request handlers contain code like the following:

item = session.query(Entry).get(item_id)

items = session.query(Entry)[:limit]

When Entry class has public attribute and objects should be shown when Entry.public is True only (the simplest example of publicity condition; in real life it might be composite and even involve related tables) we have to include this condition in queries:

item = session.query(Entry).filter_by(public=True, id=item_id).scalar()

items = session.query(Entry).filter_by(public=True)[:limit]

Note, that we already violate DRY principle (the same condition should be used every time we query Entry), but it’s still not problem. Now let’s add relation to some Child class that has similar condition for publicity. If we pass only item or items to template, we have to be careful using their data:

{% for child in item.children %}…{% endfor %}

must be replaced with

{% for child in item.children %}
{% if child.public %}…{% endif %}
{% endfor %}

In real life it becomes even more complex: a simple test for empty list is already not so simple. Do we have other options? Yes, we can pass each relation as separate variable and move filtering to the code. This will prevent mess in templates, but this won’t prevent us from using relations directly by mistake. Do you think this shouldn’t happen? We are lazy, and I doubt anybody will define separate variable for relation that doesn’t have publicity condition (yet). But life changes and eventually we might need this condition. Now one developer adds new field to the database, changes all related request handlers and (if he is a responsible person) even templates. Simultaneously (or even later, since people remember code patterns they often used) other person adds usage of this relation unfiltered in some other place and we have unpublished data leaked to public. International scandal, world war III begins (joke).

In fact, templates developer shouldn’t care about publicity of data. Unpublished data must not reach templates.
Constructing some data structures specially for templates leads to verbose request handler code instead for concise single line:

item = session.query(Entry).filter_by(public=True, id=item_id).scalar()
data = {‘id’: item.id,
        ‘title’: item.title,
        ‘date’: item.date,
        ‘body’: item.body}
data[‘children’] = children = []
for child in item.children:
    if not child.public:
        continue
    child_data = {‘id’: child.id,
                  ‘title’: child.title,
                  ‘data’: child.data,
                  ‘body’: child.body}
    if child.author and child.author.public:
        child_data[‘author’] = author = {‘id’: child.author.id,
                                         ‘name’: child.author.name}
        if child.author.company and child.author.company.public:
            author[‘company’] = {‘id’: child.author.company.id,
                                 ‘title’: child.author.company.title}

Here is statistics from one big project where I’m involved in development. The numbers below cover public segment only (internal services like editor interface are not included).

458 templates
6 databases with 210 tables
135 mapped classes, 5 of them are bases for inheritance trees
Data for 63 mapped classes must not go to public unless some condition is met (15 of them indirectly through inheritance). Those are only conditions that can’t be applied when replicating data from internal segment to public without significant impact on performance (changing state field of parent object would trigger publication or deletion of a huge list of children; using publication time in future requires some scheduler to trigger publication), the rest is filtered out before reaching database for public sites.

Having we can’t change relations behavior in request handler (this breaks ORM’s single object for each identity rule) I see the following 2 ways to solve the problem:

define separate mapped classes for public site,
instruct session to filter all ORM queries.

Both ways have problems and require separate analysis.

Перестать писать классы?

2012-03-26T19:08:00.002+04:00

Jack Diederich на конференции PyCon US 2012 сделал замечательный доклад Stop Writing Classes и добрые люди даже перевели его на русский язык. Тема очень правильная, но к этому докладу (как, впрочем, и любым другим провокационным заявлениям) очень недостаёт эпиграфом известной японской поговорки:

If you believe everything you read, better not read.

Больше всего режет глаза отказ от собственных исключений. А ведь в этом случае нам при использовании придётся перехватывать стандартные generic исключения, для возникновения которых может быть куча причин. Если во всех случаях исключение означает нештатную ситуацию (не перехватывается), то всё нормально. А если нет? Тогда вполне вероятна ситуация, когда мы думаем, что обрабатываем ошибку времени выполнения, в то время как на самом деле где-то в коде затесалась ошибка в логике, проявляющаяся на определённых данных, и потратить время на разгадывание загадок при отладке.

Теперь посмотрим на пример с классом для API. Избавились от громоздоко класса — это хорошо. Но теперь конфигурационный параметр API_KEY стал глобальной переменной, неявно используемой в функции. Implicit is better than explicit? Если это всё находится в моём небольшом скрипте, то всё замечательно. А если код запроса в сторонней библиотеке, а API_KEY нужно читать из конфигурационного файла?

И так можно продолжать со всеми остальными примерами. Урощение, в том числе и избавление от ненужных классов — это хорошо, но только нужно смотреть, насколько оно применимо в каждом конкретном случае.

Впечатления от DevConf::Python()

2010-05-21T16:12:00.011+04:00

Перед конференцией Александр Кошелев, организатор питонячьей секции, взял интервью у некоторых докладчиков:

Впечатления о докладах

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

Андрей Светлов разложил по полочкам импорт в питоне. Доклад ориентирован в основном на новичков, но и для продвинутых пользователей было немало интересного.

Андрей Власовских рассказал про свою библиотеку funcparserlib. Андрей великолепный докладчик и библиотека интригует простотой использования не в ущерб возможностям. Надеюсь в скором времени её опробовать на реальных задачах.

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

Ещё один доклад Андрей Попп посвятил созданию web-приложений на repoze.bfg. Доклад интересный, а вот сам repoze.bfg не впечатлил: не нравится мне enterprise стиль.

Виктор Коцеруба при поддержке Артема Семенова долго критиковал django. В основном по делу, но как-то очень сдержанно. Я ожидал от Виктора более провокационного изложения. По ходу доклада не все присутствующие соглашались со всеми доводами, много дискутировали.

В догонку Александр Соловьев мастерски представил альтернативу django — Svarga. Думаю, этот доклад заслуживает отдельного поста.

Во второй день Тимофей Первезенцев очень подробно и аргументированно изложил, что требуется от шаблонизаторов, и какие есть проблемы у имеющихся библиотек. Доклад вызвал много обсуждений и сильно затянулся. В результате Александру Соловьеву осталось довольно мало времени на его мастер-класс про API mercurial. Однако Александр не только уложился по времени, но и очень подробно и доходчиво показал, как с ним можно работать.

Общие впечатления

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

И напоследок фотографии с коференции, выложенные Тимофеем. Многие участники на них подписаны.

DevConf::Python() 2010 17 мая в Москве

2010-05-06T13:41:00.007+04:00

В Москве 17-18 мая пройдёт DevConf 2010 — конференция веб-разработчиков с отдельным потоком, посвящённым Python. По-моему это первое мероприятие по питону в Москве такого масштаба.

Предварительный список докладов 17 мая:

Потоковая генерация XML, Иван Сагалаев
Разработка cетевых приложений с gevent, Андрей Попп
Расширение механизма импорта в Питоне, Андрей Светлов
Внешние языки DSL на funcparserlib, Андрей Власовских
PyCharm: новая IDE для Python от JetBrains, Дмитрий Жемеров
Python и Cython, Александр Шигин
Разработка web-приложений с repoze.bfg, Андрей Попп
Django ±, Артем Семенов и Виктор Коцеруба
Разумная альтернатива Django, Александр Соловьев

Кроме того, 18 мая пройдёт весьма интересный мастер-класс Александра Соловьева "Свой gist.github.com на Mercurial".

Актуальная информация о программе секции доступна сайте DevConf 2010.

Ещё одна очень интересная фишка конференции — флип-чарты, обсуждения за маркерной доской в перерывах между докладами. Любой из слушателей может перехватить инициативу и рассказать что-то интересное по заявленной теме. Это потрясающая возможность не просто сделать доклад, а провести полноценное обсуждение интересной темы! Доклад в такой форме не требует тщательной подготовки. Ну и ещё один плюс — для ведущих флип-чартов, попавших в программу, вход на конференцию бесплатный.

Блокировка объектов при редактировании в админке

2010-05-04T20:21:00.007+04:00

Одна из недавних встреч питонеров (Moscow Python meetup) была посвещена теме NoSQL. Я отношу скептически к повсеместному переходу на NoSQL, но всё же нахожу ему применение в отдельных задачах. Так, на встрече я рассказал про блокирование редактируемых объектов на базе memcache. Проблема вполне типичная для всех редакторских интерфейсов в CMS. Один и тот же объект могут одновременно начать редактировать несколько пользователей, в этом случае правки одного из пользователей перетираются другим. Более того, иногда возникают ситуации, когда у одного пользователя оказываются открыты несколько окон редактирования одного объекта и он перетирает собственные изменения.

В моём варианте решения при открытии страницы редактирования берётся блокировка (если объект ещё не заблокирован), а затем со страницы периодически шлётся AJAX запрос на её обновление. Ответ может быть как успешный, так и нет, если другой редактор насильно перехватил блокировку. При завершении редактирования или уходе со страницы блокировка снимается. Кроме того, если блокировку не обновлять, то она через некоторое время протухает автоматически — это решает проблему снятия блокировки, хоть и с запозданием, при закрытии окна (падении браузера, выключении питания у компьютера и т.д.). Переменная edit_session необходима для решения проблемы нескольких открытых окон редактирования одного объекта, фактически она содержит идентификатор одного такого окна. Для обновления блокировки используются команды memcache gets и cas, чтобы обеспечить атомарность операций (исключить условие гонки). Ниже приведена серверная часть, слегка переписанная, чтобы оторвать от контекста нашего движка (функции и переменные сделаны глобальными).

import os, logging
from time import time

logger = logging.getLogger(__name__)

class LockError(Exception):
    def __str__(self):
        return 'Problems with object lock'

class LockedByOther(LockError):
    def __init__(self, user):
        LockError.__init__(self, user)
        self.user = user
    def __str__(self):
        return 'Object is already locked by user: %s (%s)' % \
                                (self.user.name, self.user.login)

class LockIsLost(LockError):
    def __str__(self):
        return 'The object lock is lost'

def create_lock(obj_key, user, force=False):
    '''Marks model object as editted. Returns edit session on success or
    raises exception. obj_key is global identifier of object. When force is
    True the current lock is ignored.'''
    CACHE.clear_cas()
    edit_session = os.urandom(5).encode('hex')
    value = dict(edit_session=edit_session,
                 user_id=user.id,
                 time=time())
    if force:
        if CACHE.set(obj_key, value, time=MODEL_LOCK_TIMEOUT):
            return edit_session
        else:
            raise LockError()
    for i in range(3):
        if CACHE.add(obj_key, value, time=MODEL_LOCK_TIMEOUT):
            return edit_session
        old_value = CACHE.gets(obj_key)
        if old_value is None:
            # Should try add() again
            continue
        if not old_value or time()-old_value['time'] > MODEL_LOCK_TIMEOUT:
            # Somebody's lock is already expired
            if CACHE.cas(obj_key, value, time=MODEL_LOCK_TIMEOUT):
                return edit_session
            else:
                continue
        # Somebody holds active lock, no farther attempts
        break
    else:
        logger.error('Failed to lock model object. Problem with memcached?')
        raise LockError()
    lock_user = get_user(id=old_value['user_id'])
    assert lock_user is not None
    raise LockedByOther(lock_user)

def update_lock(obj_key, user, edit_session):
    '''Updates model object lock as being active. Raises exception on
    error. obj_key is global identifier of object.'''
    CACHE.clear_cas()
    for i in range(3):
        old_value = CACHE.gets(obj_key)
        if not old_value:
            raise LockIsLost()
        elif old_value['edit_session']!=edit_session:
            lock_user = get_user(id=old_value['user_id'])
            assert lock_user is not None
            raise LockedByOther(lock_user)
        new_value = dict(edit_session=edit_session,
                         user_id=user.id,
                         time=time())
        if CACHE.cas(obj_key, new_value, time=MODEL_LOCK_TIMEOUT):
            return
    else:
        # No runtime error here since we want to give user a chance to
        # restore lock.
        raise LockIsLost()

def remove_lock(obj_key, edit_session):
    '''Removes lock for model object. obj_key is global identifier of
    object.'''
    CACHE.clear_cas()
    # We can't garuantee memcache's delete method will remove only our
    # lock, so we update the record with empty value and minimal (1 sec)
    # timeout.
    old_value = CACHE.gets(obj_key)
    # It's too late to do something in case of error, so we just ignore
    # returned value.
    if old_value and old_value['edit_session']==edit_session:
        CACHE.cas(obj_key, '', time=1)

Надеюсь, назначение и работа методов понятна из названий и комментариев.

А какие способы используете вы для организации одновременного редактирования объектов?

Автоматическая фильтрация публичных данных в SQLAlchemy

2009-12-04T20:07:00.006+03:00

В CMS в таблице для (почти) каждой сущности обычно добавляется поле-флаг, определяющее, должна ли данная сущность показываться на сайте. В коде сайта, соответвенно, необходимо не забывать добавлять соответствующее условие в каждый запрос. При использовании ORM мы автоматичеси получаем связанные сущности, для которых запрос генерируется автоматически. Это удобно, но теперь нам ещё нужно проверять, нужно ли показывать каждый из связанных объектов. Есть ещё множество ситуаций, когда такие проверки или добавление дополнительных условий также необходимы. Шансы, что в большом проекте где-то об этом забудут, близки к 100%. Поэтому очень желательно процесс фильтрации непубличных данных автоматизировать. В django для этих целей используют специально написанный менеджер. В древней библиотеки QPS с некоторым подобием ORM сделано даже лучше: можно для разных тегов выборки определить разные правила формирования запроса и даже правила переноса тегов на связанные обекты.

Как же быть с решением проблемы автоматической фильтрации в SQLAlchemy? Существует возможность при создании сессии подставить свой конструктор запроса через атрибут query_cls в sessionmaker. Но предлагаемые в архивах Google-группы sqlalchemy решения уже не работают, так как метод Query.get() теперь не предназначен для объектов с условием. Я написал свою реализацию метода, без этого ограничения. Вот что получилось в результате:

class HackedQuery(Query):

    def get(self, ident):
        # Use default implementation when there is no condition
        if not self._criterion:
            return Query.get(self, ident)
        # Copied from Query implementation with some changes.
        if hasattr(ident, '__composite_values__'):
            ident = ident.__composite_values__()
        mapper = self._only_mapper_zero(
                    "get() can only be used against a single mapped class.")
        key = mapper.identity_key_from_primary_key(ident)
        if ident is None:
            if key is not None:
                ident = key[1]
        else:
            from sqlalchemy import util
            ident = util.to_list(ident)
        if ident is not None:
            columns = list(mapper.primary_key)
            if len(columns)!=len(ident):
                raise TypeError("Number of values doen't match number "
                                'of columns in primary key')
            params = {}
            for column, value in zip(columns, ident):
                params[column.key] = value
            return self.filter_by(**params).first()


def QueryPublic(entities, session=None):
    # It's not derectly related to the problem, but is useful too.
    query = HackedQuery(entities, session).with_polymorphic('*')
    # I haven't ever seen examples with several entities, so I can test
    # this case.
    assert len(entities)==1, entities
    cls = _class_to_mapper(entities[0]).class_
    public_condition = getattr(cls, 'public_condition', None)
    if public_condition is not None:
        query = query.filter(public_condition)
    return query

Шаблонизатор в Tornado и unicode

2009-10-12T17:53:00.008+04:00

Шаблонизаторы, основанные на преобразовании кода шаблона в промежуточный питоновский код с последующей его компиляцией, как правило, отличаются простотой реализации и высокой скоростью выполнения. Tornado не исключение. Однако при использовании такого подхода возникает проблема со строками. Как бы меня не уверяли некоторые коллеги, я не верю, что верстальщику будет приятно писать в шаблоне строки в виде u'...'. Но если этого не делать, то придётся работать с 8-битными строками в некоторой кодировке, как правило UTF-8, со всеми вытекающими последствиями. Одного len() вполне достаточно. Кроме того, не хотелось бы иметь жёстко зафиксированную кодировку, пока возникает необходимость взаимодествия с сервисами компаний (вроде Яndex), не подозревающих о наличие других кодировок, кроме windows-1251.

При переходе на Python 3 всё станет работать так, как нужно. Но пока многие важные библиотеки ещё с ним не работают, приходится искать другие решения. Когда-то давно я проходил по AST и заменял все str на unicode, оставляя нетронутыми строки, содержащие только символы ASCII (это было необходимо, чтобы работали именованные аргументы). Но в Python 2.6 появилась возможность сделать from __future__ import unicode_literals. Для шаблонизатора же достаточно просто использовать соответствующий флаг при компиляции:

source = u'print repr("абв")'
code = compile(source, '

Змееводство

Не самый очевидный del

Wildcard DNS

Грязные технологии: миксины моделей SQLAlchemy

Грязные технологии: фабрика классов на основе функции

Shared memory с помощью mmap

PIL: Конвертация RGBA в RGB

Automatic filtering in SQLAlchemy: motivation

Перестать писать классы?

Впечатления от DevConf::Python()

Впечатления о докладах

Общие впечатления

DevConf::Python() 2010 17 мая в Москве

Блокировка объектов при редактировании в админке

Автоматическая фильтрация публичных данных в SQLAlchemy

Шаблонизатор в Tornado и unicode

Мысли по поводу list comprehension

Точность определения страны и региона с помощью ip2cc

ip2cc 0.5: теперь и регионы России

Несколько баз данных в SQLAlchemy и наследование

Несколько баз данных в SQLAlchemy

Нетекстовые символы в XML и HTML

Задачка для собеседования

Сохранение в SQLAlchemy под контролем

Сохранение времени в базе данных

Логгинг в базу или борьба с рекурсией

Всемогущий ssh

Борьба с обNULLением в SQLAlchemy