Очередная находка ньюба

Оказывается, что приложение Джанго не может совпадать по имени с именем проекта, причём проявилость это у меня довольно хитрым способом. Дело в том, что понадобилось мне забацать свой templatetag, создал приложение (с совпадающим именем), а Джанга ругается. Чуть потыркался, остановил девелоперский сервер, пытаюсь запустить runserver_plus из django-command-extensions, а оно мне отвечает: "Не, чувак, нет у тебя этих расширенных комманд, погляди в комманду хелп, убедись". Нормальный же runserver запускается и работает, только вот templatetag, конечно же не находит.
В целом, ещё один урок на тему, что с именами в Питоне надо быть чуть аккуратным.
P.S. И абсолютный импорт тут ничем не поможет.

Зависимости, зависимости...

У товарища тут вышла проблема с разворачиванием приложеньица на джанге. Вроде всё сделано нормально, но выдаёт, хоть ты тресни, ошибку импорта, аля "не могу импортировать 'test.settings'", но файл-то лежит рядом и из питона нормально импортируется. Битый час придумывал, откуда могут ноги у этой проблемы расти. Оказалось всё тривиально - в поставке питона идёт модуль test, поэтому возник конфликт пакетов.
Так что называйте папки (и пакеты) внятно!

О сколько нам пакетов чудных...

Пытаюсь сейчас разобрать деплоймент Django-приложений. Остановился на fabric, virtualenv и pip. Всё вроде бы интересно, но вот возникли некоторые неувязки - PIL не устанавливается через

#pip install PIL

можно, конечно использовать

#pip install http://effbot.org/downloads/Imaging-1.1.6.tar.gz

но как-то "не спортивно", поэтому захотелось использовать site-packages куда будут установлены некоторые "дефолтные" пакеты (в т.ч. PIL). Только вот окружения, созданные через virtualenv, не хотели видеть глобальные пакеты. Пришлось посерьёзней разобраться с разбором импортов в python.
Причина оказалась в том, что товарищи из Ubuntu "пошаманили" с python 2.6 и site-packages зовутся dist-packages, буквально-таки:

  if use_default_sitedirname:
      return pylib.replace('/dist-packages', '/site-packages')
  else:
      return pylib

поэтому ставить надо было не через sudo pip install/easy_install virtualenv, а с помощью sudo apt-get install python-virtualenv.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.

Чтож ещё почитать?

Дочитал Dive Into Python, как-то не очень меня впечатлила книга. Наверное, язык прост до того, что "разжёвывание" приёмов кажется черезмерным, да ещё и используемый там способ подачи материала в виде кода со сносками как-то мне совсем не по душе...
Следующей "питонистой" книгой, думаю должна стать Practical Django Projects, о которой я писал в предыдущем посте.
Или, может быть, есть что-нибудь другое стоящее внимания?

Делаем правильный суп

По совету bw решил попробовать html5lib для решения заморочки с Beautifulsoup и получилось избавиться от некрасивого воркараунда (правда, ворнинг словился):

>>> import urllib
>>> html = urllib.urlopen('http://django-newbie.blogspot.com/').read()
>>> import html5lib
>>> from html5lib import treebuilders
>>> parser = html5lib.HTMLParser(tree=treebuilders.getTreeBuilder("beautifulsoup"))
>>> soup = parser.parse(html)
/usr/local/lib/python2.6/dist-packages/html5lib-0.11.1-py2.6.egg/html5lib/inputs
tream.py:367: DeprecationWarning: object.__init__() takes no parameters
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://django-newbie.blogspot.com/feeds/posts/default?alt=rss'

Ну зачем так?

Самое загадочное в Python, на мой взгляд - ';'.join(words)
Неужто есть рациональное объяснение этому?

Суп с приключениями

Понадобилось тут вырезать адрес RSS-ленты со страничек. Ну, думаю, возьму BeautifulSoup и делов-то. Для ЖЖ всё прошло без проблем:

>>> import urllib
>>> html = urllib.urlopen('http://kurilka.livejournal.com/').read()
>>> from BeautifulSoup import BeautifulSoup
>>> soup = BeautifulSoup(html)
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://kurilka.livejournal.com/data/rss'

Ну, думаю, гораздо более демонстративно будет, если я вытяну RSS прямо для этого же блога, куда пишу сейчас этот пост. Но не тут-то было...
Упало оно с криком HTMLParser.HTMLParseError: bad end tag: u"</scr'+'ipt>". Причём, оказывается, что это программеры Google попирают спецификации W3C и не экранируют "</" в тексте скрипта. Поэтому пришлось пока сделать временную "затычку":

>>> import urllib
>>> html = urllib.urlopen('http://django-newbie.blogspot.com/').read()
>>> html = html.replace("</src'", '')
>>> from BeautifulSoup import BeautifulSoup
>>> soup = BeautifulSoup(html)
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://django-newbie.blogspot.com/feeds/posts/default?alt=rss'

Вот так и воюем: то с нестрогими спецификациями, то с нестрогим их соблюдением...
P.S. И ещё больше добила борьба с blogger.com, жестоко коверкающим тэги

Язык определяет мышление

Наверное, многие знают, что, согласно гипотезе Сепира - Уорфа, язык человека определяет его мышление и способ познания реальности. Поэтому, во-первых, программисту не стоит замыкаться на одном языке, и, во-вторых, стоит выбирать такой язык, который как можно лучше позволяет реализовывать проще и удобне решения задач, которые стоят перед разработчиком. К области веб-приложений это тоже вполне применимо.
Так вот "основой" для Django служит очень неплохой язык python: довольно простой и в то же время одновременно выразительно мощный и элегантный. Одной из наиболее ценных черт его, на мой взгляд, является целостность, т.е. все составляющие следуют общим принципам (наверное, тут снова стоит упомянуть The Zen of Python), одним из которых является There's Only One Way To Do It (Есть только один способ сделать это). Следование этому принципу уменьшает число вариантов, которые стоит рассматривать при решение задачи, поэтому разработчик тратит меньше времени и усилий, что не может не радовать. Хотя есть мнение, что ограничение свободы не есть положительная вещь, т.к. рамки сковывают "твоческий порыв". В качестве противоположной идеи сразу вспоминается перловский TIMTOWTDI. Однако, по-моему простота и скорость работы играют чаще всего определяющую роль, а если надо будет решать какие-то более "креативные" задачи, то никто не запрещает использовать другой инструмент.
В python я ещё пока совсем новичёк, поэтому для "подтягивания" своих навыков штудирую книгу Dive Into Python (текст доступен онлайн, есть и русская версия, хотя я предпочитаю читать оригинал) - довольно неплохо написано, правда стиль со сносками к исходникам мне немного не нравится.