Кстати, любой язык запросов можно реализровать в селекторах. Сейчас метод select понимает только xpath запросы, можно научить его и CSS запросам через cssselect или pyquery, например, с таким синтаксисом: select(css='....')
Признаю, дурацкий опрос вышел. Я Рассказывал в статье про доступ к DOM-дереву документа, а в опросе пытался выяснить какую либу народу юзает для сетевых операций. Кстати, в Grab есть «поддержка» pyquery, через аттрибут pyqeruy можете делать нужные вам выборки применительно к загруежнному документу.
Советую переходить на lxml+xpath, суп медленный. Хотя если объёмы парсинга небольшие, можно и его парсить.
Плюсы xml:
* более быстрый
* возможно памяти меньше ест, врать не буду, не помню
* позволяет использовать стандарт, который знают все вменяемые специалисты: xpath запросы
* есть дополнительные плюшки см модуль lxml.html
* суп раньше банально падал на некоторых типах страниц, я даже писал простенький регексп, который все javascritp выкусывал, перед тем как передать текст страницы в суп
Библиотеки для разбора DOM не включал в опрос т.к. это по сути добавило бы два измерения ответов, кто-то например использует requests + lxml, а кто-то requests + beautifulsoup, а кто-то gevent + lxml. А те кто используют Grab или Scrapy скорее всего используют их функции-обёртки для работы с DOM.
> Лучше б описал преимущества grab, а то я их перед собой не вижу :(
Преимущества Grab перед Requests трудно мне перечислить т.к. я Requests практически не использовал никогда. Всё таки Grab и Requests это разные вещи. Grab это комплексный фреймворк, а Requests это конкретно сетевая библиотека. В Grab есть так называемые сетевые транспорты, одним из которых является pycurl. Этот вариант хорошо оттестирован. Другим вариантом может быть Requests. Такой транспорт давно написан, но никто не тестирует его, а мне самому этот вариант не нужен т.к.удовлетворяет pycurl меня.
В голом виде Grab я практически не использую. Использую для всех задач Grab::Spider, вот эту штуку уже смысла нет сравнивать с Requests, только со Scrapy т.к. Spider это:
* интструмент для структуризации логики парсера вашего сайта
* удобный интерфейс для обработки асинхронных запросов
* автоматическая обработка сбойнувших запросов
* работа со списками прокси
* кэширующий слой (жутко полезная штука для отладки и не только)
* инструменты сбора статистических данных о парсинге: количество тех или иных событий, время работы различных слоёв парсера
* интерфейс работы с DOM деревом документа (описаны выше в статье)
* в данный момент я делаю рефакторинг Spider для выполнения обраотчиков на нескольких ядрах, в будущем хочу сделать кластерное решение.
Это вы щас так думаете, сколько вам 25 щас? До первой сотни ещё 75 лет жить, возможно так устанете, что мысль о дополнительной сотне будет вызывать усмешку.
Да, не так выразился, я имел в виду declarative_base — описание логики и структуры данных сразу в одном классе, раньше в алхими так нельзя было, судя по докам до 5 версии.
> PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному программисту, как весь этот зоопарк у себя собрать и поддерживать?
Думаю, надо объяснять, повышать их уровень — я не думаю, что нужны какие-то сверхусилия, чтобы установить весь этот софт. В нормальном проекте должна быть документация о разоворачивании проекта с нуля. Не важно, используется там south или нет. Верстальщикам да, им геморой с установкой локальной копии проекта не нужен.
Если ты печёшься о будущих разработчиках, то прикинь каково будет им разбираться с системой, если с единственным человеком, знающим систему, случится что-то. Например, ты станешь недоступным на долгое время, а им потом вникать, как эти rabbitmq конфигурятся. Надо щас им втолковывать.
Я так понимаю эликсир делали, когда в алхимии ещё не было своей ORM, а сейчас можно из коробки получить функционал ORM
> В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше
У тебя есть возможность передать потомкам, код использующий для миграции стандартный инструмент (South) или код, который:
а) вообще не использует миграции (т.е. еб… сь как хотите, дорогие будущие разработчики)
б) использует какой-нить адовый велосипед со специфическими багами, дающий 10% того, что даёт south
Выбор за тобой.
Меня лично мало волнуют будущие разработчики проекта. Если это будут школьники, которые не осилили south — то это проблема менеджера проекта, подобравшего таких людей, это не моя проблема. Меня волнует удобство разработки для меня, а не для будущих разработчиков.
> В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево.
В чём проблема поднять копию проекта на своей машине?
Я думаю, всё упирается в культуру и опыт разработчика(разработчиков в команде). Вменяемые люди смогут сделать миграции как с south, так и без него, смогут понять, когда south не нужно использовать а мастер-ломастеры или просто новички везде дров наломают.
Я лично south использую во всех проектах, он существенно экономит время, особенно на стадии разработки прототипа, я даже обленился и сделал fabric команду:
def automig(name):
"""
Create auto south migration and apply it to database.
"""
api.local('./manage.py schemamigration %s --auto' % name)
api.local('./manage.py migrate %s' % name)
В консоли просто пишу fab automig:someapp и получаю новую схему, автоматически изменённую под новую структуру моделей.
Ещё при работе с south имеет смысл периодически удалять старые миграции, смысла которые хранить особо нет и делать новую initial миграцию
Сейчас изучаю алхимию, меня дико ломает отсутствие south-миграций. Нашёл alembic, разбираюсь с ним потихоньку. Он тоже умеет автогенерацию миграций делать.
> Но, блин, это же такая почва для ошибок, что лучше десять раз подумать, чем вообще вводить в проект такой инструмент.
> На продакшене безопаснее мигрировать руками.
А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
> Вот это жесть… А вместо mv делаешь cp и rm?
Да честно говоря, я уже не помню когда последний раз колонку переименовывал в south Ну, скажем, если бы я работал с таблицей, содержащей миллионы строк, я бы уже задумался, как именно делать миграцию, может быть использовал бы функцию rename_column, если бы это помогло избежать изменения данных на диске.
Для очень больших таблиц south может оказаться бесполезным, например, добавление новой колонки или update значений в старой с помощью data migration может затянуться на часы и дни, если данных много. Поэтому там уже надо использовать более продвинутые методики: например копировать таблицу с данными, отключать индексы, добавлять новую колонку или update делать колонки и потом новые данные пихать в старую таблицу или переключать софт на использование новой таблицы.
> Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал.
Ты дурачком то не прикидывайся. Твои слова выше: «Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.». Я не писал, что миграции нужны всегда. Я не писал, что введение их в джангу не усложнит оную. Ты это придумал. Это факт.
Ты бы лучше по делу писал, пока вижу только эмоции.
Я хотел сказать, что двигатель прогресса не обязательно должен работать. Никто никому ничего не должен. Если кому-то интересно постигать тайны вселенной, ему от этого сухо и комфортно — ради бога. Но я не считаю, что человевечество или отдельные индивидума должны кому-то что-то. Прогресс это не цель, это лишь следствие деятельности человечества и даже скорее какой-то маленькой его части.
Например, в этом случае тоже, да.
Это ведь не догма — развиваться, прогрессировать. Ну разовьётся человечество, захватит звёзды, то-сё, дальше то что? Дрочить на свою историю и могущество?
> Оружие, бомбы для поддержания мира? Оружие создано для убийств и является основой воин.
> Да, оружие для поддержания мир
Оружие для войны или оружие для мира — это одни и те же слова. Мир и война взаимосвязанные понятия.
> Люди всегда враждуют, чтобы они не враждовали нужен либо внешний враг, против которого с радостью сплотятся, либо такое оружие, что все будут бояться его применить.
Либо изменение осознания мира, когда не будет нужды кому-то что-то доказывать. И когда потеряют значения слова мир и война.
syncdb знает, есть ключик --migrate
Уже 2-3 года юзаю south, даже не знаю, чтобы я без него делал.
Какие-то грабли раньше были, сейчас разобрался и всё работает отлично.
В случае one-to-one, оно также работает Описываем модель профиля, цепляем её и потом у нас доступно request.user.account.phone
Единственная заморочка, надо прописать создание профиля в сигналах и заполнение его дефолтными значениями.
Я как бы не против UserManager, может как-нить перелезу на него.
Плюсы xml:
* более быстрый
* возможно памяти меньше ест, врать не буду, не помню
* позволяет использовать стандарт, который знают все вменяемые специалисты: xpath запросы
* есть дополнительные плюшки см модуль lxml.html
* суп раньше банально падал на некоторых типах страниц, я даже писал простенький регексп, который все javascritp выкусывал, перед тем как передать текст страницы в суп
> Лучше б описал преимущества grab, а то я их перед собой не вижу :(
Преимущества Grab перед Requests трудно мне перечислить т.к. я Requests практически не использовал никогда. Всё таки Grab и Requests это разные вещи. Grab это комплексный фреймворк, а Requests это конкретно сетевая библиотека. В Grab есть так называемые сетевые транспорты, одним из которых является pycurl. Этот вариант хорошо оттестирован. Другим вариантом может быть Requests. Такой транспорт давно написан, но никто не тестирует его, а мне самому этот вариант не нужен т.к.удовлетворяет pycurl меня.
В голом виде Grab я практически не использую. Использую для всех задач Grab::Spider, вот эту штуку уже смысла нет сравнивать с Requests, только со Scrapy т.к. Spider это:
* интструмент для структуризации логики парсера вашего сайта
* удобный интерфейс для обработки асинхронных запросов
* автоматическая обработка сбойнувших запросов
* работа со списками прокси
* кэширующий слой (жутко полезная штука для отладки и не только)
* инструменты сбора статистических данных о парсинге: количество тех или иных событий, время работы различных слоёв парсера
* интерфейс работы с DOM деревом документа (описаны выше в статье)
* в данный момент я делаю рефакторинг Spider для выполнения обраотчиков на нескольких ядрах, в будущем хочу сделать кластерное решение.
> PostgreSQL, Solr, RabbitMQ, nodejs… И как мне объяснить обычному программисту, как весь этот зоопарк у себя собрать и поддерживать?
Думаю, надо объяснять, повышать их уровень — я не думаю, что нужны какие-то сверхусилия, чтобы установить весь этот софт. В нормальном проекте должна быть документация о разоворачивании проекта с нуля. Не важно, используется там south или нет. Верстальщикам да, им геморой с установкой локальной копии проекта не нужен.
Если ты печёшься о будущих разработчиках, то прикинь каково будет им разбираться с системой, если с единственным человеком, знающим систему, случится что-то. Например, ты станешь недоступным на долгое время, а им потом вникать, как эти rabbitmq конфигурятся. Надо щас им втолковывать.
> В реальном мире, код могут поддерживать не самые высококлассные специалисты и я считаю, что надо думать о том, кто и как после тебя будет работать с этим кодом. И чем меньше магии в нём будет, тем лучше
У тебя есть возможность передать потомкам, код использующий для миграции стандартный инструмент (South) или код, который:
а) вообще не использует миграции (т.е. еб… сь как хотите, дорогие будущие разработчики)
б) использует какой-нить адовый велосипед со специфическими багами, дающий 10% того, что даёт south
Выбор за тобой.
Меня лично мало волнуют будущие разработчики проекта. Если это будут школьники, которые не осилили south — то это проблема менеджера проекта, подобравшего таких людей, это не моя проблема. Меня волнует удобство разработки для меня, а не для будущих разработчиков.
> В что до fabric, то у нас всё куда сложнее. Дело в том, что локально код не крутится и поэтому получается так, что надо отправить последний код на разработческий сервер, создать миграцию и притянуть её в локальное дерево.
В чём проблема поднять копию проекта на своей машине?
Я лично south использую во всех проектах, он существенно экономит время, особенно на стадии разработки прототипа, я даже обленился и сделал fabric команду:
def automig(name): """ Create auto south migration and apply it to database. """ api.local('./manage.py schemamigration %s --auto' % name) api.local('./manage.py migrate %s' % name)В консоли просто пишу fab automig:someapp и получаю новую схему, автоматически изменённую под новую структуру моделей.
Ещё при работе с south имеет смысл периодически удалять старые миграции, смысла которые хранить особо нет и делать новую initial миграцию
Сейчас изучаю алхимию, меня дико ломает отсутствие south-миграций. Нашёл alembic, разбираюсь с ним потихоньку. Он тоже умеет автогенерацию миграций делать.
> На продакшене безопаснее мигрировать руками.
А ты думаешь, если ты руками делаешь изменение схемы базы данных, то это не почва для ошибок?
> Вот это жесть… А вместо mv делаешь cp и rm?
Да честно говоря, я уже не помню когда последний раз колонку переименовывал в south Ну, скажем, если бы я работал с таблицей, содержащей миллионы строк, я бы уже задумался, как именно делать миграцию, может быть использовал бы функцию rename_column, если бы это помогло избежать изменения данных на диске.
Для очень больших таблиц south может оказаться бесполезным, например, добавление новой колонки или update значений в старой с помощью data migration может затянуться на часы и дни, если данных много. Поэтому там уже надо использовать более продвинутые методики: например копировать таблицу с данными, отключать индексы, добавлять новую колонку или update делать колонки и потом новые данные пихать в старую таблицу или переключать софт на использование новой таблицы.
> Вот вроде бы и придумал, а на деле, просто задродство, уродство и цепляние к словам. И это я не придумал.
Ты дурачком то не прикидывайся. Твои слова выше: «Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.». Я не писал, что миграции нужны всегда. Я не писал, что введение их в джангу не усложнит оную. Ты это придумал. Это факт.
Ты бы лучше по делу писал, пока вижу только эмоции.
Так это и есть explicit is better than implicit Вот если бы south угадывал, что поле сменило имя, то это было бы implicit
Я вообще поля переименовываю так: создаю новое поле, далее отдельной data миграцией переношу данные и затем новой миграцией удаляю старое поле.
> Дальше спорить не буду
С тобой никто не спорит, это ты сам придумал. Я просто спрашивал у тебя твоё мнение про south, я ни в чём тебя не убеждаю.
> Если вы не понимаете, что миграции реально нужны не всегда, а введение их в джангу, лишь усложнит её, то и говорить с вами нечего.
Я не говорил, что миграции нужны всегда, ты это придумал. Я не говорил, что south надо вводить в джангу, ты это придумал.
> P.P.S. Свой шаблон можешь распечатать и съесть. Не люблю необоснованую дерзость
Пока в этом топике дерзость только за тобой замечена.
Это ведь не догма — развиваться, прогрессировать. Ну разовьётся человечество, захватит звёзды, то-сё, дальше то что? Дрочить на свою историю и могущество?
> Да, оружие для поддержания мир
Оружие для войны или оружие для мира — это одни и те же слова. Мир и война взаимосвязанные понятия.
> Люди всегда враждуют, чтобы они не враждовали нужен либо внешний враг, против которого с радостью сплотятся, либо такое оружие, что все будут бояться его применить.
Либо изменение осознания мира, когда не будет нужды кому-то что-то доказывать. И когда потеряют значения слова мир и война.
* есть такое-то состояние системы
* меняем модели
* создаём миграцию
*…
* south всё испортил
Уже 2-3 года юзаю south, даже не знаю, чтобы я без него делал.
Какие-то грабли раньше были, сейчас разобрался и всё работает отлично.
Единственная заморочка, надо прописать создание профиля в сигналах и заполнение его дефолтными значениями.
Я как бы не против UserManager, может как-нить перелезу на него.