Кодоблог

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

То, что это называется них-синдром, я узнал сегодня, случайно. Вот что пишет про это Джоел Спольски в 2001, а вот Джеймс Беннет, разработчик Django, тоже пишет про то, что когда-то их ругали за NIH, почем зря.

В общем-то, я стараюсь использовать чужие библиотеки, если они “живые”, даже пусть они и немного не доработаны.

Обычно, wysiwyg - это какая-то боль. Зачем-то нужно качать 1 мегабайтовую библиотеку и получить 100 кнопок, а потом методично отключать 90% ненужного функционала. И все равно будет тормозить и глючить. Не люблю wysiwyg. :)

Nicedit мне понравился, по первому впечатлению. Весит 35 кб, кнопочек всего 16 и все компактно лежат в gif-ке размером 3 кб. Можно конфигурировать. Синтаксис для подключения - симпатичный.

Вот так например, можно подключить его на все textarea в Django:

<script type="text/javascript" src="{{ MEDIA_URL }}js/nicEdit.js"></script>
<script type="text/javascript">
bkLib.onDomLoaded(function() {
    nicEditors.allTextAreas({iconsPath : '{{ MEDIA_URL }}js/nicEditorIcons.gif'});
});
</script>

Nicedit wysiwyg: http://nicedit.com

Это специальный пост для тех, кто не попробовал ещё Python в деле :) И особенно специально для Хаафа.

Вот такие плюсы есть у Python по сравнению с чем-нибудь ещё.

0. Painless.

В общем - главное :))) Лаконично и работает.

1. Интерактивный интерпретатор.

То есть, ставишь себе Python, запускаешь в командной строке python - и можно уже играться.

>>> a,b,c = 1,3,4
>>> max(a,b)
3

2. Мощный набор встроенных методов и типов, паттернов, базовых синтаксических конструкций

“Из коробки”, без всяких инклудов-импортов, есть списки, хэш-мэпы, min/max’ы, “декораторы”, лямбда-функции, преобразования кодировок, работа с файлами.

Примеры без экзотики:

def is_str_quoted(var):
    return var[0] == var[-1] and var[0] in ("'", '"')

var[-1] - последний элемент в var. Гениально. Отрицательная индексация - это шедевр! :)

“Нарезка” строк, списков по индексу делается универсальной конструкцией, вот так:

>>> a = 'Little Johny'
>>> 'Big ' + a[7:-1]
'Big John'

Или вот - применить ко всем элементам списка функцию и вернуть список результатов:

>>> add_ly = lambda x: x + 'ly'
>>> map(add_ly, ['rapid', 'kind', 'identical'])
['rapidly', 'kindly', 'identically']

Пояснение: lambda x: x + ‘ly’ - это функция, которая принимает x и возвращает x + ‘ly’, анонимные функции их ещё называют или лямбда-функции.

Очень часто - просто не нужны классы, хватает встроенного типа dict, чтобы представить какой-то объект:

>>> response = {'code': 1, 'message': "Hi, I'm ok."}
>>> print response['code']
1

И вот - функция с произвольным набором параметров:

def show_args(*args, **kwargs):
    times = kwargs['times']
    for i in range(times):
        for a in args:
            print a

>>> show_args('Rabbits', 'like', 'fuel', times=3)
Rabbits
like
fuel
Rabbits
like
fuel
Rabbits
like
fuel

Неименованные параметры - принимаются как список, именованные - как обычный dict (хэш-мэп).

Или вот - объявление класса, конструирование, наследование - ничего лишнего.

class GenericBoss:
    def __init__(self, owner=None):
        self.owner = owner

    def say_what_should_we_do(self):
        print self.owner.say_what_should_we_do()

class BigBoss(GenericBoss):
    def say_what_should_we_do(self):
        print "Work!"

>>> GenericBoss(owner=BigBoss()).say_what_should_we_do()
'Work!'

3. Библиотеки

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

Хорошие - это вот, например:

>>> import feedparser
>>> d = feedparser.parse("http://rudi-kodoblog.05bit.com/rss")

или

from PIL import Image
im = Image.open("bride.jpg")
im.rotate(45).save("bride_rot_45.jpg")

Для GUI, интерактивной графики - поменьше конечно, но нарождается. Есть bind’ы к C/C++ библиотекам. Вот такое даже есть - pythonogre.com.

4. Роман Ворушин и Анатолий Востряков программируют на питоне.

А это вам не хухры мухры.

:)

Нашел грабли :) Надо будет сделать баг-репорт, но пока - просто workaround.

Грабли - если view задекорирован и в нем возникает ошибка, то джанга не всегда правильно обрабатывает traceback - дебажный вывод не показывает, точнее слетает в самом дебажном выводе :)

Пример:

from decorators import render_to

@render_to('main.html')
def main_view(request):
    # тут что-то пошло не так
    raise Exception('AAA!!!')
    return context

Так вот, чтобы дебажный вывод работал правильно (как обычно), render_to должен быть объявлен:

• либо в этом же модуле view
• либо в другом package’е

Если render_to импортится из того же package, что и view, то дебажный вывод сходит с ума и не может правильно определить, в каком файле произошла ошибка.

То есть, вот так - сломается: есть views.py, где лежат views, и рядом decorators.py, в котором объявлен render_to.

Работает - так (main_view должен быть не в myproject.utils :)

from myproject.utils.decorators import render_to

# ...

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

Я нашел такое решение: http://code.activestate.com/recipes/473878/

Там - написана такая функция:

def timeout(func, args=(), kwargs={}, timeout_duration=1, default=None)
    # ...

Которую легко использовать, например, так:

def get_feed_index(url, limit=None):
    import feedparser
    data = timeout(feedparser.parse, (url,), timeout_duration=10.0)
    if data:
        # process data
    else:
        raise Exception("Reading feed timeout! URL = %s" % url)

То есть, мы захотели прочитать rss-фид, но feedparser не дает установить таймаут соединения, а ждать бесконечно долго тоже не круто. Поэтому он запускается в обертке timeout, а по таймауту выполнение просто обрывается и возвращается None. Удобно :)

Выложил сниппет: http://bitbucket.org/rudi/rudi/src/tip/python/feed_timeout.py

Ещё один декоратор по мотивам… :)

Вот “декоратор”:

def render_html(template_name):
    def wrapper(func):
        @wraps(func)
        def inner(request, *args, **kwargs):
            result = func(request, *args, **kwargs)
            if result.has_key('_redirect'):
                return HttpResponseRedirect(result['_redirect'])
            else:
                return render_to_response(template_name, RequestContext(request, result))
        return inner
    return wrapper

Вот пример его использования:

def page_edit_handler(request, slug):
    page = get_object_or_404(slug=slug)
    if request.method == 'POST':
        form = PageForm(request.POST, instance=page)
        if form.is_valid():
            form.save()
            return {'_redirect': page.get_absolute_url()}
    else:
        form = PageForm(instance=page)
    return {'form': form}
    
page_edit_view = render_html('page_edit.html')(page_edit_handler)

Комментарий к примеру: page_edit_handler выдает обычный dict, который обычно попадает в контекст, и выводится как html. Но иногда нужно сделать редирект, тогда возвращается специальный dict, с ключом ‘_redirect’.

Ключ ‘_redirect’ начинается с подчеркивания - такие ключи не работают в контексте, т.е. {{ _redirect }} выдал бы ошибку. И это - на руку нам, потому что можно использовать этот ключ для наших служебных целей, и никому это не должно помешать.

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

И комментарий второй - я специально не использовал в примере синтаксис декоратора! Если делать так, как в примере, то у нас остается “неиспорченная” функция page_edit_handler, которая может нам где-нибудь ещё пригодиться :)

Мне нравится Markdown, но не нравится, что он не переносит строки автоматически.

В этом, наверняка, есть смысл :) Но это поведение анти-интуитивно, мне удалось это проверить на неискушенных знаниями пользователях.

Сделал расширение “autobr”, которое включает авто-перенос, выложил здесь: http://github.com/rudyryk/markdown-flavours/

Кстати, такую модификацию я встречал на нескольких сайтах, на том же GitHub, но исходников мне не попадалось.

UPD 25 Dec 2011. Новая ссылка на репозиторий: https://github.com/05bit/python-mdxflavours

Inspired by http://vorushin.ru/blog/26-decorators-python :)

Например, если у меня есть view для удаления чего-нибудь - скажем, файла:

def remove_file(request, id):
    #...

И мне нужно показать страницу с подтверждением удаления - простую “да / нет”. Я написал декоратор, который может работать вот так:

def confirm_context(request, id):
    context = {}
    # ...
    return RequestContext(request, context)

@confirm_required('confirm_remove.html', confirm_context)
def remove_file(request, id):
    #...

Оригинальный view при этом не модифицируется, что радует.

Теперь при вызове view проверяется POST-запрос на наличие в нем ключа “__confirm__”, либо другого - это определяется необязательным параметром декоратора “key”. Если ключа нет - показывается страница подтверждения. Если есть - вызывается оригинальный view.

В шаблон подтверждения передается контекст, созданный функцией “confirm_context”. Это обычная функция, которая принимает те же параметры, что и изначальный view.

Собственно, код декоратора:

def confirm_required(template_name, context_creator, key='__confirm__'):
    def decorator(func):
        def inner(request, *args, **kwargs):
            if request.POST.has_key(key):
                return func(request, *args, **kwargs)
            else:
                context = context_creator and \
                    context_creator(request, *args, **kwargs) \
                    or RequestContext(request)
                return render_to_response(template_name, context)
        return wraps(func)(inner)
    return decorator

ПС. Надо будет подправить верстку блога, а то сниппеты не влезают нормально по ширине.

Классика жанра - отформатировать вывод цены: “1000” вывести как “1 000”. Наверное, после ещё пары-тройки лет программирования на питоне у меня получится написать это покороче :))

Пока же - вот:

def nice_price(price, delimiter=','):
    """
    Красиво отформатировать цену - через каждые 3 знака
    ставится разделитель, копейки не учитываются.
    
    Примеры
    -------
        >>> print nice_price(1000)
        1,000
        >>> print nice_price(10500)
        10,500
        >>> print nice_price(123000, ' ')
        123 000

    """
    try:
        price = int(price)
    except TypeError:
        price = 0
    
    nice = ''
    while price >= 1000:
        nice = delimiter + '%.3d%s' % (price % 1000, nice)
        price = price / 1000
    if nice:
        nice = '%s%s' % (price, nice)
    else:
        nice = '%s' % price
    return nice

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

Типичный пример использования - красивый такой paginator, у которого текущая страница всегда в центре списка страниц.

Когда я встретил такую задачу, то использовал простое “лобовое” решение. Все отлично сработало :) Над усовершенствованием можно будет подумать в следующий раз, если такая задача попадется снова.

Вот оно:

def get_center_slice(full_list, slice_size, selected):
    """
    Обрезать список по указанной длине, чтобы выбранный
    элемент оказался в центре списка.
    """
    list_len = len(full_list)
    slice_next = slice_size/2
    slice_prev = slice_size - slice_next
    
    start_index = selected - slice_prev + 1
    end_offset = 0
    if start_index  list_len:
        start_index = max(0, start_index - end_index + list_len)
        end_index = list_len
    
    return full_list[start_index:end_index]