- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
def read(self):
self._skip_whitespace()
ch = self._peek()
if ch in ',:[]{}':
return self._read(), None
elif ch == 'n':
return self._read_literal('null'), None
elif ch == 't':
return self._read_literal('true'), True
elif ch == 'f':
return self._read_literal('false'), False
elif ch == '"':
return self._read_string()
elif ch in '-0123456789':
return self._read_number()
else:
raise UnexpectedCharacter(ch)
Просто взять и уебать таких писателей. httpstream/jsonstream.py
Follow us!
Ох, блять, это еще не все, как оказалось. Все из того же замечательного файла
Обычный парсер генератор создаст какой-нибудь LL(1), или, если нельзя, то LR(1), или можно попробовать PEG (packman parser) - все с хорошо известной асимптотикой и т.д.
Но тут дело в том, что захотелось парсить не все сразу, а с остановками, на манер как SAX может парсить XML. И в этом есть определенный смысл, начиная примерно с мультимегабайтных файлов.
Но в пределах этой библиотеки бультимегабайтные файлы не ожидаются, т.как парсится HTTP ответ от базы данных. Если он будет таких запредельных размеров, то пользоваться этим будет не возможно, даже если памяти на это много и не потребуется. Пользователь на другом конце не станет ждать часами ответа.
ок. тогда без bison/flex. что делает парсинг json из тривиального простым. как раз случай для fsm. и если делать в нативном питоне, то итеративность можно реализовать yield'ами. (я корутинами не пользовался, я такое только через коллбэки реализовывал.)
Естесственно, я в первую очередь себя проверял, искал может я что-то не так записал изначально, может быть "Е" - это на самом деле какой-то другой символ, который так странно отобразился и т.д.
Вообще так испахабить идею... это я как бы пытаюсь научиться работать с графовыми базами данных. И, ну просто диву даешся какие идиотские идеи люди приделывают к, вобщем, замечательному основанию. Посмотреть на тот же Сайфер / Гремлина - это ж просто пиздец. Язык который умеет так мало, и при это в нем столько сущностей... Безумная какая-то грамматика, к которой документ был написан каким-то филателистом любителем.
И нормального интерфейса к базе данных нет, т.как сама база написана на Яве, и создатели, естесственно, постарались энтерпрайз налепить. Как встроенную, ее еще можно использовать - но это значит, писать на Яве, т.как ее больше никуда не встроишь. А использовать ее из чего-то другого - пайплайн становится таким невероятно тормозным, что херит на корню все плюшки вобщем-то принципиально очень быстрой бд.
teh drama
> teh drama
есть такие как мы, которые это говном называют.
а есть продвинутые которые клиентам под это дело консалтинг продают и еще больше энтерпрайза лепят - и бабло большое за это имеют.
А что, есть стандартный потоковый pull-парсер? Вижу json.iterencode, iterdecode не наблюдаю.
Появилось свойство на входе - преобразовали и записали в выход. Если нужно что-то аккумулировать, аккумуляторы выводим последними.
Это даёт возможность обрабатывать большие массивы данных небольшими ресурсами и относительно простым кодом.
К примеру, есть xml-ки в 10Гб и json-файлы аналогичного размера, которые надо конвертировать / заливать в базу. На таких масштабах наивные подходы не работают.
В любом случае, имея pull-парсер, легко построить push-парсер и вообще реализовать любое удобное апи.
Покупаем больше памяти, и 10 гиг в нее входят ;)
Нищебродский сервак. Всего 90 гигов. Само собой этого не хватит...
я конечно повторяюсь, но если у вас 10Гб файлы, но выбор xml как формата файла был очевидно ошибочным. с json я догадываюсь те же яйца. форматы для структурированых данных очень плохо подходят для представления структурированного потока данных.
Ключи повторяются, но вот либа, похоже, не утруждает себя их интернированием. Разбираться не стали, просто переписали.
Но мы говорим про парсер, т.е. про чтение а не про запись. В каком случае нам не нужно будет прочитать весь ответ от сервера? Зачем мы тогда этот запрос посылали вообще? Кроме того, по занимаемой памяти - вовсе не факт, что строка будет занимать меньше памяти, чем собраный объект (числа представленные строкой занимают больше памяти, ключи многих объектов будут почти наверняка повторяться).
Тут было уже упомянута разница между пуш / пул парсерами. Ну вот предположим мы действительно получили очень большой ответ и хотим его переправить по частям дальше по инстанции: опять же, нам ничто не поможет выбросить уже посланные объекты до того, как мы не прочитаем весь объект на верхушке иерархии. Т.е. ради мнимого удобства (а на самом деле просто очевидно потому, что очень хотелось сделать самому) получили и потерю производительности, и баги, и кучу других проблем.
> Задумку авторов того, что в посте, я, разумеется, не одобряю и не оправдываю.
XML'ки бывают не только в ответах от сервера. Например стартовая выгрузка того же ФИАС'а (реинкарнация КЛАДР'а) содержит 8 гиговую XML'ку.
Ваш кэп.
?