1. Что ты думаешь об in-browser тестах? То есть интеграционные теста некоего HTTP API выполняемые из браузера клиента каким нить JS скриптом. Правильно ли это?
2. Правильно я понимаю, что при тестировании Views мы ограничиваемся только тестом входящих данных в наш рендер, но нам все равно во что они превратятся? Какие способы можешь предложить для тестирования именно результата рендеринга? Selenium конечно круто, но хотелось бы ограничиться server-side тестами.
Спасибо(:
habrahabr.ru
Интересны методы защиты программ от бесконечных циклов, выхода за границы массивов, лишних отступов, ошибок других таких-же-умных-и-невнимательных. Ах да, еще нужен секрет счастья: как не перепутать set, list и tuple.
Python Fastest Web Framework
mindref.blogspot.com
Python Fastest Template Engine
mindref.blogspot.com
Python Web Routing Benchmark
mindref.blogspot.com
Python Web Reverse URLs Benchmark
mindref.blogspot.com
Python Web Frameworks PEP8 Consistency
mindref.blogspot.com
В посте #1753626 замерял скорость работы своей библиотеки ubjson против библиотек json (да-да, апельсины против яблок!). Результаты были печальны, но ожидаемы. Тем временем посидев-подумав, докрутил производительность до +20-40%. Еще открыл для себя cython: +50% к скорости сверху за просто так весьма неплохо - нужно будет прикрутить его при установке как опцию. sys.version : '2.7.3 (default, Jul 5 2012, 08:55:40) \n[GCC 4.5.3]' sys.platform : 'linux2' * [test_1] Handle 4KB sized CouchDB document with various data * [cython] Decoded in 52.938107 (0.000529 / call) * [cython] Encoded in 60.032089 (0.000600 / call) * [native] Decoded in 105.954515 (0.001060 / call) * [native] Encoded in 106.602120 (0.001066 / call) А вот PyPy на кодировании выдал какую-то сумашедшую цифру затраченного времени, возможно из-за обильного использования itertools.chain. Нужно разбираться. sys.version : '2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jul 15 2012, 19:18:28)\n[PyPy 1.9.0 with GCC 4.5.3]' sys.platform : 'linux2' * [test_1] Handle 4KB sized CouchDB document with various data * Decoded in 20.009146 (0.000200 / call) * Encoded in 126.725331 (0.001267 / call)
hg.python.org
Сначала думал, что это болезнь только ElementTree, но, видимо, ее маштабы куда больше.
docs.python.org
или вкратце
python.org
вот смотрю и думаю: "блин, а может к черту эту 2.х, особенно с поддержкой 2.4?"
@Lance за оперативное решение проблемы в конференции в 3 ночи, хотя не знаю сколько у него сейчас.
Вот так, работаешь над одним проектом, а находишь баги для другого. Теперь SleekXMPP из develop ветки будет работать с jabber.ru и прочими серверами, имеющими АААА запись, но к которым нельзя подключиться, потому что клиент тупо не умеет ipv6, например. Спасибо youtube.com
Все чаще и чаще ловлю себя на той же мысли: зачастую классы просто не нужны и можно обойтись простыми функциями.
1. не смотря на набор -костылей- слоя совместимости простой бенчмарк отностительно python 3.x показал прирост производительности +10% относительно безкостыльной версии только для ветки 2.х;
2. операция .decode('utf-8') очень тормозная для python 2.x;
3. при добавлении разных проверок версий, можно выйти с минимальными потерями производительности — это дешевле холстого вызова функций совместимости;
4. six хорош как прокси, но u() и b() станут первым местом для оптимизаций;
5. городить совместимость всего и вся на уровне библиотеки, работающей только с байтами, при полной юникоидности всего жутко неудобно;
6. в целом, если навести порядок с тем, где у нас ходят байты, а где юникоды, то жить очень даже можно — больше всего времени потратил на приведение тестов в порядок т.к. там с этим делом был полный бардак в отличии от.