Потоковая проблема чтения
Я использовал ElementTree для нескольких проектов и рекомендую его.
Это - pythonic, прибывает 'в поле' с Python 2.5, включая c версию cElementTree (xml.etree.cElementTree), который в 20 раз быстрее, чем чистая версия Python и очень прост в использовании.
lxml имеет некоторые преимущества производительности, но они неровны, и необходимо проверить сравнительные тесты сначала на вариант использования.
Насколько я понимаю, код ElementTree может легко быть портирован к lxml.
5 ответов
Идея состоит в том, что данные могут быть недоступны в то время, когда вы вызываете Read ... или когда-либо. Например, в NetworkStream данные могут поступать медленнее, чем вы их собираете. Или вы можете быть близки к концу FileStream. Stream может знать, что осталось меньше байтов, чем вы запрашивали, или он может не иметь возможности узнать, когда или будет ли получен полный удар запрошенных байтов. Поэтому вместо того, чтобы ждать данных, которые могут никогда не поступить, или с ошибкой «недостаточно байтов, угадайте еще раз», Read оставляет за собой право вернуть меньше, чем вы запрашивали.
Следовательно, при чтении фрагмента в массив байтов , возможно, вы не заполняете массив байтов. Но вы хотите, чтобы следующий фрагмент был добавлен туда, где остановился последний, а не перезаписывал начало массива байтов.
В первом примере используется объявленный размер байтового массива 1000 в качестве входного параметра в методе Read .
Второй пример - чтение одного байта из потока время, которое отлично подходит для потоковой передачи входящих или исходящих данных - то есть, если вы можете обрабатывать части получаемого потока без предварительной буферизации всего этого целиком в памяти, это более эффективный подход.
Я думаю, где вы запутались здесь автор искусственно ограничивает пример максимум 1000 байтами. Многие протоколы, которые включают потоковую передачу, обычно отправляют байт или два в начале, специально уведомляя потребителя о длине потока в целом, чтобы он мог лучше всего разбивать и обрабатывать поток, поэтому объявленный предел в 1000 не требуется. Вы получаете размер,
Не понимаю, зачем читать метод читал бы откуда угодно из потока? Он не читает весь поток?
Чтение позволяет указать начальную и конечную точки для чтения. См. Ответ Итоулсона для получения дополнительной информации.
То, что я пытаюсь понять, Метод чтения начинает читать конец и запишите все байты в указанный диапазон в массив байтов.
Если это был вопрос, я полагаю, ответ будет отрицательным. Метод Read заполняет массив данными из потока в указанных начальной и конечной точках.
Почему он использует bytesRead в качестве начальной точки в s.Read (data, bytesRead, dataLength-bytesRead);
He использует bytesRead для отслеживания «количества прочитанных байтов». Это позволяет ему узнать, с чего начать чтение при следующем вызове Read.
Фраза «мог читать где угодно от 1 до 1000 байт» означает «мог читать 1 байт или 2 байта, до 1000 байт». Он относится к длине прочитанных байтов, а не к местоположению. Чтение будет расположено в текущей позиции потока.
На основании того, что я читал документацию по методу чтения, поскольку потоки могут использоваться для чтения самых разных источников данных, от ввода с клавиатуры до файлов и сетевого трафика, он был оставлен открытым для конкретная реализация, будут ли данные, возвращаемые методом чтения, возвращать запрошенное количество байтов. Например, если конкретная реализация для чтения сетевых данных хочет вернуть 500 байтов данных, доступных на данный момент для веб-запроса, но ожидает, что это не будет сделано, пока не будет прочитано 1000 байтов, а вы запросили 1000 байтов, он может вернуть то, что у него есть, чтобы вы могли его обработать. Он сообщит вам, что он прочитал только 500 байт, и вы должны знать, что их может быть еще больше. Максимум 1000 - это просто показатель того, что вы не