Неа, пока каких-то инструментов для сравнения нету. Библиотека пишется спонтанно. Естественно, если вы будете писать своё решение, то будучи заточенное под задачу он будет быстрее Grab работать.
Пожелания по железу. Используя асинхронность вы скорее всего упрётесь раньше в CPU или жёсткий диск или в канал. Также учтите что для парсинга Grab использует только одно ядро.
Хорошо, что вы комментарий написали, а то тут так пусто :)
Curl я почти выпилил уже. Ну из Grab то его, допустим, можно лего вытащить и юзать urllib, сейчас транспорт почти готов. А вот из Spider вытащить то я уже вытащил, но альтернативой пока что может служить только пул тредов (или процессов) а это значит, что собо много потоков нельзя будет запустить — cpu убьётся или память. В общем, я эти фичи щас попиливаю потихоньку. Чувствую, где-то в течении месяца уже работающие вещи будут.
Первым и последним. Больше не с чем сравнивать :) Если кто-то накидает ещё ссылок на похожие проекты — буду благодарен. И правильно говорить о сравнении Grab:Spider и Scrapy. Ибо Grab это нечто другое — это API для синхронных сетевых запросов и обработки полученных ответов. Grab скорее надо сравнивать с urllib2, urllib3, requests, pycurl, mechanize.
Для того, чтобы сравнить, нужно для начала определиться по каким критериям сравнивать. Этакую матрицу критериев выработать. Я уже сам не знаю, что получится через год из Spider. Хочется верить, что сделаю поддержку работы Spider на кластере :) И ещё хочется допилить selenium. А ещё я там недавно вынес код работы с сетью в отдельный слой (в Spider, в Grab это давно уже) и теперь можно реально делать работу Spider на других сетевых библиотеках: twisted, gevent, pool тредов или процессов.
С urllib всё в порядке. Просто для подключения к википедии надо указывать реальный User-Agent. Возможно что-то ещё, я давно не заморачиваюсь такими вещами т.к. в Grab все нужные заголовки генерируются.
> или это для каких-то других целей сделано?
`g.search`, по-умолчанию, работает с уникодом и ищет в unicode-представлении документа. То есть вам не нужно думать, в какой кодировке документ, вы можете всегда исползовать unicode-аргумент для поиска. Если же вы хотите искать таки байтовую строку, то нужно передать дополнительный аргумент `byte=True`, тогда поиск будет происходить в `g.response.body`.
> Написание своей обертки для xpath приведет к написанию… xpath! Причем скорее всего менее расширяемого и, возможно, более тормозного. Так зачем?
Регекспы работают очень быстро. Естественно не нужно заново изобретать xpath, достаточно очень простого синтаксиса, чтобы описать пару самых распространнённых случаев:
1) найти тэг с заданным class/id
2) найти тэг с заданным class/id, у родителя которого заданный class2/id2
3) У тэга из 1 и 2 получить аттрибут какой-нибудь
4) У тэга из 1 и 2 получить содержимое.
Не нужна расширяемость, нужна быстрая реализация простых паттернов.
Горизонтальное масштабирование хорошо, когда есть под рукой облако, желательно бесплатное :) В этом направлении я тоже копаю постепенно, например, щас в grab:spider можно разбить выполнение задачи по ядрам, но особого прироста это не даёт, двукратное ускорение на моём четырёхядерном-athlon. Да и ещё оказалось, что модуль multiprocessing не шибко удобная штука, распараллеливание по сети в нём вроде как вообще нету. Думаю посмотреть в сторону какого-нить pyro
А что регекспы? Регекспу /<div[^>]*>([^<]+) абсоюлтно пофиг, какой документ, валидный или нет, он просто ищет текст внутри div-тэга.
Вся сложность с регекспами в том, что очень сложно описать вложенные тэги. Банальное xpath выражение "//div/div" с помощью регкспов описывается монстрообразным (не проверял):
SAX непременим для разбора невалидных XML. Все сайты невалидные. Чтобы получить валидный XML из битого HTML, нужно затратить усилия, сравнимые с построением DOM-дерева. Поправьте, если я ошибаюсь.
Пожелания по железу. Используя асинхронность вы скорее всего упрётесь раньше в CPU или жёсткий диск или в канал. Также учтите что для парсинга Grab использует только одно ядро.
Curl я почти выпилил уже. Ну из Grab то его, допустим, можно лего вытащить и юзать urllib, сейчас транспорт почти готов. А вот из Spider вытащить то я уже вытащил, но альтернативой пока что может служить только пул тредов (или процессов) а это значит, что собо много потоков нельзя будет запустить — cpu убьётся или память. В общем, я эти фичи щас попиливаю потихоньку. Чувствую, где-то в течении месяца уже работающие вещи будут.
Скачать можно с порнолаба, например: pornolab.net/forum/viewtopic.php?t=1193902
`g.search`, по-умолчанию, работает с уникодом и ищет в unicode-представлении документа. То есть вам не нужно думать, в какой кодировке документ, вы можете всегда исползовать unicode-аргумент для поиска. Если же вы хотите искать таки байтовую строку, то нужно передать дополнительный аргумент `byte=True`, тогда поиск будет происходить в `g.response.body`.
> что будет более рационально?
docs.python.org/library/timeit.html
:)
Регекспы работают очень быстро. Естественно не нужно заново изобретать xpath, достаточно очень простого синтаксиса, чтобы описать пару самых распространнённых случаев:
1) найти тэг с заданным class/id
2) найти тэг с заданным class/id, у родителя которого заданный class2/id2
3) У тэга из 1 и 2 получить аттрибут какой-нибудь
4) У тэга из 1 и 2 получить содержимое.
Не нужна расширяемость, нужна быстрая реализация простых паттернов.
Горизонтальное масштабирование хорошо, когда есть под рукой облако, желательно бесплатное :) В этом направлении я тоже копаю постепенно, например, щас в grab:spider можно разбить выполнение задачи по ядрам, но особого прироста это не даёт, двукратное ускорение на моём четырёхядерном-athlon. Да и ещё оказалось, что модуль multiprocessing не шибко удобная штука, распараллеливание по сети в нём вроде как вообще нету. Думаю посмотреть в сторону какого-нить pyro
Вся сложность с регекспами в том, что очень сложно описать вложенные тэги. Банальное xpath выражение "//div/div" с помощью регкспов описывается монстрообразным (не проверял):
<div[^>]*>\s*<div[^>]*>(.(?!))+\s*