Комментарии 53
отличная библиотека, уже достаточно давно работаю с ней. сильно упрощает жизнь =)
раньше был свой велосипед, но после знакомства с grab необходимость в нём отпала.
есть еще один очень удобный инструмент (фрэймворк) для парсинга — scrapy, где-то на хабре была статья про него. эти 2а инструмента полностью перекрывают все мои рабочие потребности.
раньше был свой велосипед, но после знакомства с grab необходимость в нём отпала.
есть еще один очень удобный инструмент (фрэймворк) для парсинга — scrapy, где-то на хабре была статья про него. эти 2а инструмента полностью перекрывают все мои рабочие потребности.
>>> g.go('youporn.com')
…
Мы сделали запрос к гуглу
Куда куда, простите? Точно к гуглу? :)
> Также можете заказывать у меня написание парсеров, граберов, скриптов обработки информации.
Это вам лучше бы на PHP так как он доступнее (хостинги) и обычно парсеры требуют именно на нем.
Это вам лучше бы на PHP так как он доступнее (хостинги) и обычно парсеры требуют именно на нем.
Есть множество заказчиков, которые не против python. Говорю по собственному опыту. Даже на одеске регулярно публикуются заказы на парсеры, где люди сами пишут, что нужна система на python или указывают этот язык одним из вариантов. PHP я забыл как страшный сон. Множество версий PHP, несовместимых между собой и сами с собой (на ризличных хостинг-конфигурациях) не доставляли особой радости :) Типичный пример парсера на PHP — веб страница с простым интерфейсом, запускающая большой процесс внутри mod_php и благополучно умирающая по таймату с пустым экраном т.к. логинг ошибок отключен скриптописателем или админом веб-хостинга. А если скрипт всё же смог отработать он вываливает стопицот мегабайт данных прямо в окно браузера :) На питон такие волности допустить трудно т.к. как прикруить к нему веб-интерфейс — ещё знать надо. Поэтому даже у говнокодеров шансы сделать что-то работающее выше. Да и вообще для работы нужен хотя бы ssh-доступ к VPS или шаред-хостингу, этим отсекаются совсем дубовые заказчики, которые сэкономили на хостинг со школьных завтраков.
НЛО прилетело и опубликовало эту надпись здесь
Очень просто. Я реально устал от причуд PHP и стал искать язык, куда бы свалить. Был выбор между ruby и python. А Perl я уже знал до этого и он мне не нравился. Я почитал про ruby и увидел в нём всякие фишки, напоминающие perl, меня это не сильно обрадовало и так я выбрал python. Его фича с выделением блока табулированием — я в неё влюбился сразу — это гениально :) Так что выбор был эмоциональным. По поводу рынка я никогда не парился. Python-программисты нужны, например, часто вакансию публикуются о django-вакансиях. В общем веб-кодинг востребован. Человек с реальными знаниями нигде не пропадёт. Даже в таких компаниях как яндекс, рамблер, mail.ru есть вакансии для python-разработчиков.
вы сейчас какую-то чушь написали про php, и про таймаут, и про лог ошибок, и про вывод в окно броузера.
Я написал впечатления, полученные эмпирическим путём. Я сам писал такую чушь, а потом мне в руки попадала такая чушь и это чуши очень много в интернетах каждый день пишется. Вообще, я считаю, что любой программист в первые годы становления себя как профессионала пишет преимущественно чушь. На php взращивается гораздо больше программеров, чем на питоне, отсюда и количество чуши на нём больше. А ещё я выражаю следующую мысль: лёгкость написания веб-интерфейса на php порой оказывает отрицательное воздействие на качество некоторых программ, в частности, парсеров и граберов, которые по природе своей процессы фоновые. Когда их пытаются оформить как часть веб-интерфейса, то получаются различного рода неприятности.
Заступлюсь за php, хотя тоже собираюсь сваливать с него на python как проект закончу, но щас вот этот проект на php как раз занимается парсингом десятков тысяч страниц ежедневно, и скажу что при определенных совершенно не больших знаниях, php прекрасно работает по 14 часов(конечно может и больше, это у меня столько он работает) в консоли, добавить надо 3-4 строчки.
Не уверен в том что первые две грамотные, но они работают, нужны для того чтоб выводить в режиме реального времени информацию.
Потом задаюм бесконечный таймаут.
И если надо увеличиваем количество допустимой памяти.
ob_implicit_flush(true);
ob_end_flush();
set_time_limit(0);
ini_set('memory_limit', '2048M');
Не уверен в том что первые две грамотные, но они работают, нужны для того чтоб выводить в режиме реального времени информацию.
Потом задаюм бесконечный таймаут.
И если надо увеличиваем количество допустимой памяти.
Парсеры на PHP? Мсье знает толк в извращениях
Как дела обстоят с basic auth и всяческими кастомными хедерами?
Кастомные хедеры шлются опцией `headers` — она описана в статье. Для базик авторизации настройки нету, ни разу не нужна оба была. С любым недостающим функционалом можно работать через `curl` аттрибут — это объект pycurl, который умеет всё на свете :)
Теперь basic auth доступен и через интерфейс Grab: bitbucket.org/lorien/grab/changeset/042fbe0f5797
а чем mechanize не устроил?
Он какой-то нечеловеческий, пару раз пробовал его использовать и бросал. Документации не нашёл толковой. Я сейчас уже плохо помню, давно это было.
НЛО прилетело и опубликовало эту надпись здесь
Немного разные акценты у библиотек — скрапи — это реально паук такой, бегает по сети, тянет в тыщу потоков информацию. А grab — это скорее швейцарский нож, вы его берёте и начинает вдумчиво колупать сайт. Асинхронной многопоточности в grab нет, всё что вы можете — это создать несколько tread-объектов и в каждом работать с grab. Но лучше только скачивать, у меня были проблемы с использованием lxml-модуля в нескольких потоках. Т.е. скачиваем в несколько потоков, парсим HTML в одном потоке. В curl есть некий multicurl, дающий эту самую асинхронность, но за несколько лет у меня так и не возникло острой надобности разобраться с ним. Это у меня в планах.
Всё-таки в таком деле, как разработка грабберов, асинхронная модель рулит. Я бы посоветовал приглядеться к scrapy повнимательнее — в мою недолгую бытность фрилансером он меня здорово выручал. А швейцарский нож тут скорее сам питон — всё что можно легко делать в grab, так же просто реализуется в scrapy.
Для работы с cURL могу под питоне еще порекомендовать human_curl (pip install human_curl) или вот репозиторий: github.com/lispython/human_curl
Использовать можно как:
или так, используя базовую авторизацию
В свое время видел grap, но именно по той причине, что он занимается процессингом контента страницы не стал его использовать.
Использовать можно как:
>>> import human_curl as requests
>>> r = requests.post('http://h.wrttn.me/post', files=(('file_1', '/tmp/testfile1.txt'),
... ('file2', open('/tmp/testfile2.txt'))), data={'var_name': 'var_value'})
...
>>> r.status_code
201или так, используя базовую авторизацию
>>> import human_curl as hurl
>>> # unfortunately hulr.it keep this name :-)
>>> r = hurl.get('http://h.wrttn.me/basic-auth/test_username/test_password', auth=('test_username', 'test_password'))
>>> r.status_code
200
>>> r.content
'{"username": "test_username", "password": "test_password", "authenticated": true}'
В свое время видел grap, но именно по той причине, что он занимается процессингом контента страницы не стал его использовать.
На самом деле, по-умолчанию он почти что ничего и не делает со страницей, функции преобразования в уникод и построения DOM-дерева включаютс только когда идёт обращение к методам, отвественным за работу с DOM-деревом. Первоначально grab разрабатывался как обёртка над curl, но затем я невольно наблюдал как акцент смещается на обработку полученной информации. И это круто — очень удобно :) Мне.
Супер! А куки можно словарем передавать?
Расскажите пожалуйста, какое отличие этой библиотеки от Beautiful Soup? Поддержка сетевых функций?
Процитирую сам себя:
BeautifulSoup — это только четвёртый пункт из представленного выше списка. Я давно отказался от BeautifulSoup — он тормозной, менее стабильный чем lxml и не поддерживает xpath и множества других вещей из модуля lxml.html, которые так скрашивают жизнь.
Это библиотека для парсинга сайтов. Её основные функции:
1) Подготовка сетевого запроса (cookies, http-заголовки, POST/GET данные)
2) Запрос на сервер (возможно через HTTP/SOCKS прокси)
3) Получение ответа сервера и его первоначальная обработка (парсинг заголовков, парсинг cookies, определение кодировки документа, обработка редиректа (поддерживаются даже редирект в meta refresh тэге))
4) Работа с DOM-деревом ответа (если это HTML-документ)
5) Работа с формами (заполнение, автозаполнение)
6) Отладка: логирование процесса в консоль, сетевых запросов и ответов в файлы
BeautifulSoup — это только четвёртый пункт из представленного выше списка. Я давно отказался от BeautifulSoup — он тормозной, менее стабильный чем lxml и не поддерживает xpath и множества других вещей из модуля lxml.html, которые так скрашивают жизнь.
lxml + xpath + firebug (copy xpath) в сто тысяч раз лучше и проще Beautiful soup.
Есть также замечательная библиотека requests с более приятным API, на мой взгляд.
Боже, как раз уже месяц занимаюсь этим BeautifulSoup, lxml, mechanize, scrapy… будем пробовать теперь и это
на редкость удачно библиотека получилась, реализация логики программы с помощью граба по большей части чисто описательный процесс: зайди на этот сайт, заполни форму, нажми сабмит, посмотри есть ли на странице вот эта строка, дай-ка теперь мне вон то значение из таблицы и т.д.
меньше действий (и кода) — меньше вероятность ошибки, + встроенная система ведения логов позволяет контролировать результат каждого запроса.
меньше действий (и кода) — меньше вероятность ошибки, + встроенная система ведения логов позволяет контролировать результат каждого запроса.
>>> g = Grab()
>>> g.setup(post={'act': 'login', 'redirec_url': '', 'captcha': '', 'login': 'root', 'password': '123'})
>>> g.go('habrahabr.ru/ajax/auth/')
хотел сказать, что такой интерфейс для отправки POST запроса мне кажется бесчеловечным. в мире TDD есть лучшие примеры, реализующие ту же функциональность. прямо мм… как некоторые шоткаты на хабре)
А почему в примере User-Agent не изменился? Так и должно быть?
Никак не могу найти про треды?
Скачать 1 раз 1 сайт — это как говорится много ума не нужно.
У меня по 600к запросов в день идет, Ваша либка потянет?
Использую свой велик, но он уже стал феррари ) ( использует pycurl + треды)
Скачать 1 раз 1 сайт — это как говорится много ума не нужно.
У меня по 600к запросов в день идет, Ваша либка потянет?
Использую свой велик, но он уже стал феррари ) ( использует pycurl + треды)
600k запросов это 6 запросов в секунду или например 6 тредов параллельных по 1 запросу в секунду. Не вижу ничего необычного. Потянет или нет, зависит от вашего железа и настроек ОС. Вам есть смысл переходить на grab только если вам больше нравится его API, скорости он вряд ли вам прибавит. Чем больше одновременных соединений вам нужно, тем больше следует думать о том, чтобы перейти на асинхронную модель работы с сетью. Я лично с асинхронной нагрузкой практически не работал т.к. не было задач таких, поэтому в граби и отсутсвует интерфейс к multicurl.
Сори за оффтопик:
есть постоянные вакансии для Pyhton(Django) программистов в офисе в Минске, на хороших з-п (до 3к). Если интересно пишите — skype tankgen
есть постоянные вакансии для Pyhton(Django) программистов в офисе в Минске, на хороших з-п (до 3к). Если интересно пишите — skype tankgen
Тут попробуйте: pyjob.ru pep8.ru/job
Клиентские https сертификаты SSL/TLS умеет? Было бы очень полезно.
Объясните, пожалуйста, как можно отключить опцию request_cookies.
Я использую Grab и Tor. В тот момент, когда начинается бан, я меняю identity в Tor. Cookie отключены. Тем не менее, бан не снимается. Однако, если перезапустить скрипт, то бан снимается. С чем это может быть связано?
Кто-нибудь grabил сайты на GWT?
А есть ли что-то похожее, но уже современное?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Grab — python библиотека для парсинга сайтов