py.user.next
он блоком называет набор строк, то есть это никакого отношения к блочному чтению не имеет

py.user.next
в задании - работа со строками => нужен текстовый режим

Budulianin
Чем хуже режим ‘rb’ ?

py.user.next
во-первых, в третьем питоне есть разница, что возвращается из файла, строки или байтовые объекты
так как строки - наборы юникодовых точек, то и символы там могут быть любые
следовательно, из файла он может прочитать что угодно, и искать в них можно тоже что угодно

py.user.next
во-вторых, в бинарном режиме рассматриваются лишние символы; например, возврат каретки будет рассматриваться как символ, хотя это не нужно, а иногда даже ошибку может вызвать (если start задать конкретно с переводом строки \n, то она не совпадёт из-за возврата каретки, я уж не говорю о том, что строку в байтовом объекте искать нельзя (для удобства допустил, что ты её перевёл в байтовый объект))

py.user.next
в-третьих, текстовый режим даёт кроссплатформенность, то есть это значит, что скрипт, применяемый в разных системах, проводит сравнения одинаково, и не нужно писать n разных кодов, которые учитывают различия

py.user.next
то есть, где-то может быть \r - ты пишешь код, который её учтёт, а где-то нет \r - получается, первый код делает лишнюю работу в таком случае, учитывая то, чего нет и не будет на данной системе

py.user.next
и ещё: не делай того, чего никто не делает - не преумножай сущности без необходимости
то есть, если тебе чего-то не надо, то и на всякий случай это делать не надо

Budulianin
А как же быть с виндой и 26 символом ? :) Это такая редкость, что не стоит так заморачиваться?

Budulianin
Да, Python 3.x возвращает bytes. Я Python 2.x пользуюсь, там str возвращает.

Budulianin
Строку искать в байтах нельзя, просто у меня Python 2.x. и у меня там str.

Budulianin
Т.е. в Python 3 из-за юникода, символ #26 не прервёт чтение файла на винде, в текстовом режиме?

Budulianin
Обычно файл читаешь построчно и даже, если \r там появляется, то он никак не мешает( если будет \r\n то конец строки норм воспронимается, если только \r то текстовый режим тоже не поможет, всё сольётся в одну строку )

[guest@localhost py]$ echo -en "a\rb\rc" >file.txt
[guest@localhost py]$ .hex file.txt
00000000  61 0d 62 0d 63                                    |a.b.c|
00000005
[guest@localhost py]$

>>> f = open('file.txt', encoding='utf-8')
>>> next(f)
'a\n'
>>> next(f)
'b\n'
>>> next(f)
'c'
>>>

>>> f = open('file.txt', encoding='utf-8')
>>> s = next(f)
>>> s
'a\n'
>>> 'a\n' in s
True
>>> f = open('file.txt', 'rb')
>>> s = next(f)
>>> s
b'a\rb\rc'
>>> b'a\n' in s
False
>>>

Budulianin
А как же быть с виндой и 26 символом ? :) Это такая редкость, что не стоит так заморачиваться?

py.user.next
Обычно файл читаешь построчно и даже, если \r там появляется, то он никак не мешает( если будет \r\n то конец строки норм воспронимается, если только \r то текстовый режим тоже не поможет, всё сольётся в одну строку )

py.user.next
$ echo -en “a\rb\rc” >file.txt

~$ echo -en 'a\rb\rc' > file.txt
fin = open('file.txt')
next(fin)
'a\rb\rc'

py.user.next
если даже там есть такое, то файл нужно сначала подготовить, а не закладывать эту туфту в нормальный скрипт

py.user.next
какой-то “индус” пропёрся (индус - это образно, это и америкос мог быть), а ты из-за этого свои программы коверкаешь - это не дело

Budulianin
Это ты Python3.x пользуешься, а Python 2.x нетакой догадливый.

>>> import codecs
>>> f = codecs.open('file.txt', encoding='utf-8')
>>> next(f)
u'a\r'
>>> next(f)
u'b\r'
>>> next(f)
u'c'
>>>

Budulianin
Обработать его предварительно, удалив эти символы?

Budulianin
Но это нужно обрабатывать файл повторно, с большими файлами затратно, легче уж в бинарном режиме, если такая ситуация.

Budulianin
Cтал замечать, что в Python2.x больше косяков, чем в Python3.x.

py.user.next
если будешь бинарно обрабатывать текстовые файлы, станешь индусом
а это очень вредно - заполнить голову всякой ерундой; а потом строить стены, а к ним лесенки

py.user.next
там дофига таких косяков
почему ? потому что сначала пишут и пробуют расклады разные, а потом становится ясно, какие прижились, а какие лучше удалить вообще

Budulianin
Согласен, но когда можно реализовать решение, без повторной обработки файла, через бинарный режим, лучше уж так сделать, если данные в таком виде перемешенном.

Budulianin
Это высказывание, точно так же применительно и к Python 3.x, он же тоже развивается

py.user.next
только разница есть: в первом и втором питоне всё сырое, поэтому там много кардинальных изменений, а в третьем и последующих уже всё почищено