- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
li = item_parser.select('//li')
for i in li:
try:
i.extract().index(u'Цены')
item.price = i.select('span/text()').extract()[0]
except ValueError:
pass
try:
i.extract().index(u'Модификации')
item.modification = i.select('span/text()').extract()[0]
except ValueError:
pass
try:
i.extract().index(u'Отзывы')
item.reviews = i.select('span/text()').extract()[0]
except ValueError:
pass
Follow us!
все это try:
i.extract().index(u'Цены')
item.price = i.select('span/text()').extract()[0]
except ValueError:
pass
в цикл тоже надо
По идее должен выбрать первый текстовый узел. Или select() в любом случае списков возвращает?
ЗЫ. А если так:
> первый текстовый узел
разве в xpath не с единицы индексация?
или какой менеджер пакетов используется. Дальше найти в, например, /usr/lib/python2.7/site-packages/ (или соответствующей версии) соответствующии биндинги и их можно либо запустить в отладчике (gdb, для этого нужны debuginfo) либо скомпилировать самому с записью в лог.
http://govnokod.ru/15385#comment220790
Вот сука, что меня бесит, этот ваш ёбаный фитон можно юзать без сишкоблядства?
Другое дело непродуманые интерфейсы, типа как в С++ или Яве. Там волей-неволей приходится выбирать либо велик, либо dll/jar hell.
По поводу Виндовса - не скажу, т.как очень давно не приходилось пользоваться. И как-бы не вижу смысла им пользоваться для программирования, только в качестве платформы на которой конечный продукт должен работать. Но могу предположить, что Питон-модули можно собрать разными компиляторами, и в зависимости от этого и отладочный механизм будет разным.
- для того, чтобы знать жаву, нужно знать жаву.
- для того, чтобы знать питон, рано или поздно придется разбираться в си, потому что часть написана на си, потому что альтернативы этому нету - питон слишком тормознут и динамичен.
>По поводу Виндовса - не скажу, т.как очень давно не приходилось пользоваться.
Еще один. Ну понятно, питоноблядь же.
>И как-бы не вижу смысла им пользоваться для программирования, только в качестве платформы на которой конечный продукт должен работать.
Так именно с этим у него и проблемы. Как ошибки на клиентских машинах отлаживать будем? Бля, с таким отношением к винде виндузятникам надо повально юзать дотнет.
Просить сохранить крешдамп (или сохранять его автоматом) и копаться в нем какой-нибудь вижуалкой. Ну или пытаться воспроизвести на своей виндовой машине. Как еще то. Кто тебе даст отлаживаться на клиентской машине...
Но с тобой я согласен, у уважающего себя девелопера должна быть виндовая машина (хотя бы виртуалка), причем желательно с разными версиями винды. Кросскомпиляция из-под линуха - та еще срань, а в плане разбора полётов - вообще не вариант.
Самому воссоздать ошибку на винде.
>Но с тобой я согласен, у уважающего себя девелопера должна быть виндовая машина (хотя бы виртуалка),
Я хотел сказать не это, а то, что питон - вендовраждебное говно. Алсо на питоне часто пишется серверная хуйня.
К сожалению не всегда получается. Бывают настолько хитровыебанные сочетания сборок Windows XP 2025 от Васи-Долбоёба, каких-нибудь твикеров, вирей, антивирей, яндекс баров и рукожопого админа приходящего мальчика, что на нормальной машине тебе эту ошибку никогда в жизни не воспроизвести...
+1000
ССЗБ. Это проблемы любого вендо- (а возможно и прыще-) софта, и как-то с ними живут.
Я не знаю, как в остальном обстоят дела, но предполагаю, что в более-менее нетривиальной программе пришлось бы использовать чужеродные модули. По аналогии с пи-инвоками в Сишарпе.
Все остальное - вообще бред уровня здешних троллей, просто набор слов без смысла.
Нативные контролы это все-таки SWT, через который рисуется морда эклипса.
Swing всё рисует сам в жабе, оттого тормознут и убог.
SWT это просто реинкарнация AWT.
Хм, значит я ступил ;) Спасибо.
Как часто такое желание появляется? Гуй, наверно, главное исключение. А в питоне это - необходимость. Вся стандартная библиотека на нем.
>Все остальное - вообще бред уровня здешних троллей, просто набор слов без смысла.
Тефлоновые трусы надень, чтобы не пригорало.
Пример нетривиального использования: хочется добавить аггрегатную функцию к Сиквелайту (Сиквелайт предусматривает такую возможность). Нужно будет написать собственно функцию на Си + обвязку для Явы.
Хочется в многопроцессорную архитектуру: MPI/OpenMP - опять же, интерфейсы есть для Си и Фортрана, на Яве нужно использовать обвязки.
Какую-нибудь мат. библиотеку типа ЛАПАКа - опять же.
Я на Яве очень мало пишу. Да и на Питоне не часто...
По моему опыту (очень ограниченому), реализовывать обвязки на Яве сложнее чем для Питона, и нет такой сильной мотивации ввиду другой области применения. Да и есть еще такой момент, что огромное количество програмистов на Яве элементарно не знают, даже не то, как это сделать, а что это в принципе возможно. Типичное решение на Яве для работы с инородным модулем - написать СОАП сервер и общаться с ним по ХТТП, пересылая друг другу ХМЛи. Потому что так в институте учат.
Эм, а к каким СУБД нынче поставляются не pure java дрова? Ну если не брать в расчет встраиваемые базы типа sqlite и беркли.
Совсем не поэтому... Жаба это ж энтерпрайз, тут другие приоритеты ;)
1) Можно запустить инородный модуль где-то на другой машине, на виртуалке, в песочнице, под другим юзером - где душе угодно. Имеет смысл, например, если модуль проприетарный и виндовый, а жабоконтейнер крутится на линухе.
2) Инородный модуль через внешний протокол никак не может крашнуть жабомашину (что он или его обертка с удовольствием сделают при интеграции через JNI).
3) Масштабируемость - покупаем больше машин, поднимаем больше экземпляров сервиса...
4) Удобство при смене технологии - надо переписать на другом языке - да пожалуйста, XML парсеры-генераторы везде есть.
P.S. Естественно, я не предлагаю приделывать SOAP интерфейс ко всякой мелочи, которую вызывают по миллиону раз в секунду в тесном цикле :) Всему свои технологии.
Так что остается писать более-менее законченный расчетный модуль целиком на сишке\фортране, и цеплять его к жабе через soap :)
Ну вот пример, Нео4Ж, у которого АПИ = ХТТП сервер. В таком виде он нахер не нужен, т.как по производительности быстрее на калькуляторе посчитать.
По поводу JDBC - ну так все равно кроме случаев, когда база данных написана на Яве, как-то нужно налаживать связь с Сишным / С++ кодом. Будет ли эта связка написана на Яве или на Си ситуации не изменит, только перенесет интерфейс с нативным кодом в другое место.
Кроме того, если уж мы взяли к примеру базы данных. На Яве просто нет возможности сделать некоторые вещи, которые возможно, например, в Монго на ж.скрипте, Киотокабинете и Редисе на Луа, БелойБД на питоне, для чего, опять же нужно было бы писать обвязки для Явы.
Драйвера баз данных всё-же обычно общаются через сокет по бинарному протоколу. Реализации JDBC через ODBC мост имели место быть, но они всегда считались костылём и имели неприемлимую производительность.
По сути можно судить о том, реализован ли драйвер на чистой жабе, по наличию этого драйвера в maven central.
Дык все клиент-серверные реляционки (да и даже та же монга и редис) работают через сокеты/пайпы. Отсюда и Type 4 дрова на чистой жабе, которым сишка вообще нахер не нужна... И интерфейс с нативным кодом уже есть - сокет, на котором СУБД слушает запросы.
А вот если речь идет о прикручивании user-defined функций на жабе к серверу СУБД или о запуске скриптов прямо в контексте этого сервера - тут другое дело. Эффективно пристроить жабу с этой стороны, имхо, почти нереально ;(
Я вот недавно задался целью написать обвязку для БелойДБ (на КЛ). Отличительная особенность этой БД в том, что хранилище находится в общей памяти. Вот реализовал я необходимые Сишные функции и дальше не могу придумать хорошего способа ими воспользоваться :( Очень хочется обойтись без сериализации, ну или по крайней мере без сериализации в процессе обмена данными с БД. Хранить-то все равно как-то нужно.
Ну во-первых на локалхосте сокеты работают через общую память, и не такие уж и медленные (а на другом хосте кроме сокета вариантов тупо нет).
А во-вторых те самые одбц дрова один хрен работают через тот же сокет ;) Ну мне не попадались умеющие в шаренную память... Да еще и лишние преобразования добавляют...
Поэтому вполне логично, что от выпиливания ненужной прослойки скорость стала выше...
> обойтись без сериализации
А как? В лиспе же всяко нельзя трогать внутренние представления объектов... Поэтому как не крути, а одно преобразование всяко нужно.
Дальше, даже если закрыть глаза на очень ограниченый набор типов (кроме флоатов, строк и блобов по-сути ничего и нет), чтобы полноценно с ними работать нужно:
- функции в самой БД (осуществимо но...).
- иметь какую-нибудь обобщающую стратегию, как это делать. Например, питоновская реализация обвязки предлагает использовать "запрос" + "курсор", соответственно с накладными расходами на то и другое, ну и запрос можно сформулировать только используя небольшое (всего штук шесть) количество функций умеющих сравнивать записи.
- знать, какие свойства и структуры могут оказаться полезными. Например, можно легко построить полный (complete) граф - но толку от такой структуры никакого. Можно попытаться написать функцию ищущую spanning tree - но нужно ли это для решения каких-то реальных задач, и какого рода данные могут быть в таких задачах?
На самом деле, последний вопрос самый сложный, т.как у графов ну очень много разных свойств, и понять какие из них фундаментальные и нужные, а какие - бесполезные очень тяжело...
Пруф?
А не находится. Скорее всего я как всегда нагнал ;(
Насчет скорости: когда я тестил передачу потока - получалось 12-18Гб\с на локалхосте. Куда уж быстрее? latency не замерял.
- первое чтение из хранилища в структуры языка БД.
- результат запроса из языка БД в язык драйвера.
- из языка драйвера в какой-нибудь специальный формат, который дальше переводится в структуры прикладной програмы.
- прикладная програма это все еще дальше во что-то переделывает, типа какого-нибудь ХМЛ.
Это не страшно, когда на каком-то этапе данных становится совсем немного (типичный веб, для формирование ХТМЛ страниц и т.п.) но если это, например, поиск молекул белков, то такая схема работы совсем плохая.
что-то оракл совсем другого мнения - процедуры пишутся либо на pl/sql, либо как раз на жабе
а также как минимум ibm и авторы h2, пруфлинки выше по треду
Ну h2 вообще на жабе, на чем там еще мутить хранимки ;)
На всём, что поддерживает JSR-223?
А есть какие-нибудь движки, поддерживающие этот стандарт, кроме изкоробочного rhino?
Полно. На вскидку Groovy, Clojure, JPython, JRuby, MVEL.
Не слишком ли это небезопасно? Как я понимаю, кривая библиотека может положить весь процесс/явомашину.
Орлы? Классические утечки памяти в жава коде невозможны.
Тролсто
Это реально серъезная проблема явы - код написанный на ней постоянно страдает утечками памяти, в сишкокоде, например такое практически невозможно.
На яве практически невозможно написать библиотеку без утечек, другое дело лисп, луа, сишка и питон.
В Си есть тенденция избегать выделять память где угодно кроме стека, т.е. только на время выполнения функции. А в Яве рантайм заточен под выделение памяти в куче, в том числе и особенно для недолго живущих небольших объектов. Это с одной стороны делает написание кода проще, а с другой, просто не заметить ошибку, когда какие-нибудь небольшие объекты не удаляются мусорщиком. Иногда, чтобы обнаружить такую ошибку програма должна выполнятся несколько дней, что в тестовых условиях тяжело воспроизвести.
Я, например, еще не видел, чтобы Эклипс проработал больше одной-двух недель без перезапуска. Идея может сейчас чуть по-лучше стала, но еще два года назад ее нужно было перезапускать как минимум раз в день.
Да причем тут мусорщик. Объекты не удаляются по одной причине - если мудак, писавший либу, где-то закешировал ссылку на этот объект и потом забывает ее занулить\заменить\удалить. При таком подходе оно утечет в абсолютно любом языке.
1. Какой-то умник решил изобрести свой кэш, а вот про слабо-мягкие ссылки никогда не слышал. Лечится пинком и использованием нормальных кэшей.
2. Кто-то решил загрузить в хэш-табличку всё содержимое базы данных/индексов. Лечится лимитированием используемых ресурсов: пакетной потоковой обработкой / настройкой отношения Xmx и внутреннего буфера.
Явовский подход к решению любых задач: нафигачить кучу синглтонов, которые что-то создают, что-то кешируют, неявно формируя глобальное состояние, и тут очень легко пропустить какую-нибудь настройку по умолчанию, которая приведет к тому, что какие-нибудь объекты, зачастую вообще не известные програмисту использующему эти синглтоны будут где-то зачем-то накапливаться.
Можно подумать, это только в "Яве". В любом практически применимом языке (пока не рассматриваем обратимые вычисления на квантовых компьютерах) есть ресурсы, которые нужно освобождать. Это вещь, которая обычно не зависит от языка. Различаются лишь подходы к управлению ресурсами.
Синглтон, кстати, даже в жабе считается говпаттерном.
И сишники тоже так и не научились не юзать глобальную херню... Вон тот же v8 сколько лет не мог создать 2 инстанса скриптового движка в одном процессе... А вся стандартная сишная либа насквозь пронизана статическим говном. Да, его где-то закостылили через thread-local, где-то обвешали мутексами, и оно даже стало потокбезопасным, но говно то осталось.
Так что тут не жаба виновата, а ленивые быдлокодеры, которым не хочется передавать контекст явным образом или юзать IoCC...
Проблема именно в том, что кэш не очищается, синглетоны тут не при чём.
К примеру, недавно встретил занятную реализацию кэша: кэш зачитывается целиком по таймауту. Т.е. на коллекцию заводится отдельный тред, которые просыпается каждые N минут и зачитывает всё содержимое в память.
Мне тоже, кеши тут вообще не при делах ;) У синглтонов полно других проблем. Причем абсолютно тех же самых, что и у обычных глобальных переменных.
и виноваты в этом, разумеется, синглтоны, а не намеренно отсутствующие локи?
"If you use the sqlite3_prepare() API to create prepared statements, each prepared statement is considered to be a part of the database connection from which it was derived. So you cannot run two prepared statements originating from the same database connection in different threads at the same time."
>Кто-то решил загрузить в память мир
Возможно на любом языке, нет?
Ну так британские учёные нигде и не написали, что их исследование относится только к Java.
Естесственно, механизм один и тот же в любом языке. Речь не о механизме, а о разных подходах к решению тех же задач.
Зачем так много букв? Напишите прямо: ява - говно, в отличие от флеша, например, который никогда не течет и не падает.
Поздравляю с профессиональный днём
Это как? :)
Или выкини двойку нахуй, или хотя бы import unicode_literals
Что делает первая строка? Это типа if? :) Или побочно-ориентированное программирование?
Но я не знаю, что это за парсер такой. Вроде не lxml, а суп вообще вроде ХПуть не понимает.
Сегодня попробую сделать нормально, бо старшой из отпуска прийдет.
Прости..
тоже мне, мечта жизни - поглазеть на сиськи деушки, которая тебе никто.
увидеть сиськи и умереть.