Python-сообщество

К слову, немножко смешная история о том, как в одной команде многоуровневый индекс строили: http://ivory.idyll.org/blog/mar-10/storing-and-retrieving-sequences

Большое спасибо, посмотрю.

По поводу кэша - теперь понятно. Пойду смотреть, что можно в Linux получить на эту тему. Надеюсь, в /proc есть всё-всё-всё.

я бы взял символ конца строки посложней и читал с конца. Например ‘;\n’

Zubchick
я бы взял символ конца строки посложней и читал с конца. Например ‘;\n’

В задаче топикстартера подойдет и ‘\n’ с конца файла читать я почти уверен.
Но если усложнять до огромных объемов и юникода, то мой вариант проще чем индекс строить :) Хотя он и невозможен, если изначально логи написаны без ‘;’

Отредактировано (Ноя. 27, 2010 18:30:33)

Андрей Светлов
Для другой кодировки - иные правила. И я не уверен, что у всех кодировок ‘\n’ (байт с кодом 10) не сможет
встретится в середине символа. Эти китайцы - они такие странные люди, мне мама говорила.

for hglyph in xrange(0x4e00, 0x9fa6):
    if bytearray('\n') in bytearray(unichr(hglyph), encoding='utf-16'):
        print unichr(hglyph),

Андрей Светлов
Стоит ли огород городить?

doza_and

Subideal Ox
Более того, в коде у doza_end строка может оказаться длиннее MAX_ROW и seek точно также может попасть в середину многобайтного символа (shit happens). То есть сивол выйдет поломанным - тоже мелочь, но неприятно. Соответственно, ‘rb’ в open - это совсем не решение обсуждаемой проблемы

Я что-то не понял. Первая часть предложения - по поводу строка окажется длиннее.  Она не окажется в силу заявленного ограничения (которое можно установить при записи лога). Но по-моему это не имеет отношения к делу.
Вторая половина предложения. Символ окажется поломанным. Запросто. Для работы алгоритма важно только чтобы ‘\n’ в двоичном потоке был валидным разделителем (те в имеющихся сообщениях не было внутри этого символа что конечно не всегда можно гарантировать). но если это так, то после разбиения строка правильно разрежется с нужным выравниванием (как мне кажется я это не проверял).

doza_and
кстати - все открывают файл в текстовом режиме - в доке написано: seek для текстовых файлов дает непредсказуемый результат.

Ээээ. Кажется, уже все всё поняли.
Гордостью Королевских Мушкетеров никто себя не объявлял.
Прыгать через .seek по произвольному смещению в текстовых файлах и ожидать, что будет работать всегда - не стОит. Зависит от…
Надеюсь, все согласны.

Обсуждение получилось действительно интересным.
Меня, например, заставило еще раз взглянуть на связь символов-байтов.
Измерить скорость - результат вышел немного неожиданным. Я знал, что построчная вычитка файла в пару мегабайт очень быстрая. Теперь имею цифры.
Остался неисследованным еще один интересный аспект.
В python3 появился пакет io. Очень замечательный. open(…, ‘r’) и open(…, ‘rb’) возвращает на самом деле разные классы.
Я видел в рассылке питона обсуждения на эту тему - но сильно не вникал.
Берем текстовый режим.
Очень интересно, как операции на вложенном байтовом потоке могут повлиять на поток символов.