LXML — проблемы с кодировкой при парсинге HTML

Нет, это не я. Это наглое воровство:-(

Django vs Rails: дилемма начинающего web-разработчика

Там тоже есть GIL.

Django vs Rails: дилемма начинающего web-разработчика

А какое есть «волшебство» с GIL?

Django vs Rails: дилемма начинающего web-разработчика

Ключевое в вашей проблеме это — «в эклипсе». Девелопмент сервер отлично перезагружает код после изменения. Не у всех IDE получается с этим интегрироваться.

Code Like a Pythonista: Idiomatic Python (part1)

Я это не утверждаю. Ваш пример не имеет отношения к «передаче по значению».

Есть объект int со значением 1 и на него две ссылки «a» и «b». Cледом создается объект int со значением 2 и в «b» помещается ссылка на него.

Если вы вместо 1 и 2 сделаете список или любой другой объект, то будет тоже самое.

Code Like a Pythonista: Idiomatic Python (part1)

> В питоне переменная содержащая, например, объект типа int по-умолчанию будет передана по значению, а переменная содержащая объект типа list — по ссылке.

Нет. В питоне всё ссылки, даже int. В питоне есть различие только в mutable/immutable'ности объектов…

Вышел PyPy 1.2 и ускорил Python в разы!

Извините, но пока не понимаю о какой поддержке вы говорите. В Джанге, разве там как-то особенно обрабатывается взаимодействие с mod_wsgi? И имеет ли это большое значение при работе проекта?

Как вы считаете, для каких задач оптимальней mod_wsgi, а для каких fcgi?

Вышел PyPy 1.2 и ускорил Python в разы!

А не могли вы рассказать, почему fcgi не конкурент mod_wsgi?

Вышел PyPy 1.2 и ускорил Python в разы!

А какие «плюшки языка» вы бы советовали использовать?

Развертывание сайта на Джанго, используя FastCGI

В lighttpd нет mod_wsgi (а если бы и был по той же архитектуре построен, то обладал бы теме же проблемами что и в nginx только ещё хуже — у лайти один воркер вообще), а в apache да есть, и да работает.

Развертывание сайта на Джанго, используя FastCGI

Тут вы совсем не правы. Нельзя сравнивать WSGI и FastCGI — они на разных уровнях ответственности оперируют. Первый это по сути дырка, а второй это провод с переходником который в неё втыкается.

Потом, mod_wsgi в nginx не работает. Вот просто не работает по одной просто причине — любая обработка запрос, которая уходит в mod_wsgi лочит весь воркер nginx. Если для раздачи файлов (а nginx до недавнего времени лочил воркеры и на этой операции из-за синхронного обращения к диску) это не критично, так как файлы обычно маленькие и отдаются зачастую напрямую из файлового кеша OS, то при мало-мальски серьезном приложении внутри mod_wsgi это становится большой проблемой.

По этой же причине проект по сути и умер.

Развертывание сайта на Джанго, используя FastCGI

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

Асинхронный http-клиент, или почему многопоточность — лишнее

> что, понятное дело, убивало все к черту на счетных циклах

Убивало не это, а то что тред, отпустив GIL, мог сам же его снова захватить. Так было из-за того, что он не знает есть ли кто-то другой ждущий выполнения, а OS в свою очередь не успевала в этот интервал переключить контекст.

В новом варианте он отпускает его сам только если флаг выставлен и потом засыпает до того момента как GIL захватит другой тред.

То что всю эту системы перевели на временные интервалы в место числа инструкций, можно сказать, побочный эффект нового подхода:-)

Асинхронный http-клиент, или почему многопоточность — лишнее

А говорили что питон 2.5:-)

Слишком мало повторений. На таких объемах накладные расходы на переключение GIL не так отчетливо проявляются. А полученный временной результат может зависеть от общей нагруженности системы в какой-то конкретный момент запуска теста.

Суть в том, что треды как минимум не быстрее в CPU-bound задачах.

Асинхронный http-клиент, или почему многопоточность — лишнее

Трудно анализировать такое поведения, не видя код.

Асинхронный http-клиент, или почему многопоточность — лишнее

> но на нём одном к сожалению не реализовать ничего сложного,

что вы имеете ввиду?

Асинхронный http-клиент, или почему многопоточность — лишнее

Вот как раз тут у вас нет умножения:-)

Лучше вообще взять классический пример с счетчиком:

COUNT = 100000000
CPU_COUNT = 4

def count(n):
while n:
n -= 1

def sequence():
for i in range(CPU_COUNT):
count(COUNT)

def parallel():
pool = []
for i in range(CPU_COUNT):
t = threading.Thread(target=count, args=(COUNT,))
t.start()
pool += [t]

[t.join() for t in pool]

Асинхронный http-клиент, или почему многопоточность — лишнее

Если вы делаете просто:

for i in range(2500000):
1000 * 1000

то интерпретатор оптимизирует это выражение и умножения просто не будет при каждой итерации.

добавьте: * i

тогда увидите реальную картину при которой вариант с тредами медленнее.

Django multiple database support — теперь поддерживает множественные соединения с базами данных

Я бы не признался ;-)

Django multiple database support — теперь поддерживает множественные соединения с базами данных

ты не прав