Не удается прочитать Python до конца файла - PullRequest
4 голосов
/ 04 сентября 2011

Я пробовал это несколькими разными способами, но результат всегда кажется одинаковым. Я не могу заставить Python читать до конца файла здесь. Он останавливается только на полпути. Я пробовал бинарный и ASCII режимы, но оба имеют одинаковый результат. Я также проверил наличие каких-либо специальных символов в файле, где он обрезается, и их нет. Кроме того, я попытался указать, сколько читать, и он все еще отключается в том же месте.

Это выглядит примерно так:

f=open("archives/archivelog", "r")
logtext=f.read()
print logtext

Это происходит независимо от того, звоню ли я из bash или из python, являюсь ли я обычным пользователем или пользователем root.

ОДНАКО, он работает нормально, если файл находится в том же каталоге, что и я.

f=open("archivelog", "r")
logtext=f.read()
print logtext

Это работает как сон. Есть идеи почему?

Ответы [ 4 ]

3 голосов
/ 04 сентября 2011

Справочное руководство по Python о read() гласит:

Также обратите внимание, что в неблокирующем режиме может быть возвращено меньше данных, чем было запрошено, даже если нетБыл задан параметр размера.

Существует также проект PEP по этому вопросу, который, очевидно, не был принят.PEP - это Предложение по улучшению Python .

Так что печальное положение дел заключается в том, что вы не можете полагаться на read(), чтобы получить полный файл за один вызов.

Если файл представляет собой текстовый файл, я предлагаю вам использовать readlines().Это даст вам список, содержащий каждую строку файла.Насколько я могу сказать, readlines() является надежным.

2 голосов
/ 04 сентября 2011

Спрыгивая с ответа Келкетека:

Я не могу вспомнить, где я читал об этом, но в основном сборщик мусора Python запускается «изредка», без каких-либо гарантий относительно того, когда данный объект будет собран. Функция flush() делает то же самое: http://docs.python.org/library/stdtypes.html#file.flush. Я понял, что flush() помещает данные в некоторый буфер для записи, и ваша ОС решает, когда это делать. Возможно, одна или обе из них были вашей проблемой.

Читали ли вы файл вскоре после его записи? Это может привести к состоянию гонки (http://en.wikipedia.org/wiki/Race_condition),, которое является классом обычно странных, возможно, случайных / трудно воспроизводимых ошибок, которые вы обычно не ожидаете от языка высокого уровня, такого как Python.

1 голос
/ 04 сентября 2011

Хорошо, сначала напишу это в блокноте, чтобы я не нажимал «ввод» слишком рано ...

Я решил проблему, но я не совсем уверен, ПОЧЕМУ решение решает проблему.

Как выяснилось, причина, по которой один смог прочитать, а не другой, заключалась в том, что тот, который был обрезан раньше, был создан с помощью скрипта Python, тогда как другой был создан ранее.

Несмотря на то, что я закрыл файл, файл, по-видимому, не был полностью записан на диск, ИЛИ, когда я его захватывал, это было только то, что было в буфере.Нечто подобное.

Делая:

 del f

И затем, пытаясь получить файл, я получил весь файл.И да, я использовал f.close после записи файла.

Итак, проблема решена, но может ли кто-нибудь дать мне причину, почему мне пришлось собирать мусор вручную в этом случае?Я не думал, что мне придется делать это в Python.

1 голос
/ 04 сентября 2011

Метод read возвращает содержимое файла кусками.Вы должны вызывать его снова, пока он не вернёт пустую строку ('').

http://docs.python.org/tutorial/inputoutput.html#methods-of-file-objects

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...