Файл с текстом параграфа
Файл с текстом параграфа
Скачать файл: Файловый ввод и вывод
Re: Файл с текстом параграфа
1. Фразу «из всех специальных символов в текстовых файлах могут быть только символы перехода на новую строку» возможно стоит смягчить до «как правило, кроме символов перехода на новую строку специальные символы в таких файлах не используются»?
2. Текстовый файл – это "устройство" последовательного доступа…» - возможно слово устройство лучше заменить на что-то типа «объект последовательного доступа» или «структура данных, к которой осуществляется последовательный доступ»?
2. Текстовый файл – это "устройство" последовательного доступа…» - возможно слово устройство лучше заменить на что-то типа «объект последовательного доступа» или «структура данных, к которой осуществляется последовательный доступ»?
Re: Файл с текстом параграфа
Про спецсимволы в текстовых файлах звучит странно, соглашусь (не очень понятно, что именно называется спецсимволами; например, \t, \r -- это спецсимволы или нет?). Тоже сложно предложить лучшее, не зная специфики питона.
"Чаще всего открытый файл блокируется, и другие программы не могут использовать его." -- странное заявление, во-первых, это зависит от ОС, во-вторых, от режима открытия файла, я бы сказал, что чаще всего дела обстоят ровно наоборот. Лучше это вообще удалить, а рассуждения о блокировке перенести в режимы открытия файла.
Часть разговора о файловом курсоре напрашивается перенести в самое начало, где речь идет об открытии файла. Зачем вообще открывать файлы? (Это один из примеров мест, где лучше избегать появления новых понятий без объяснения). Потому что, раз файл -- это набор данных, то нам надо указать, с каким элементом набора мы хотим работать. Однако доступ к элементам почти всегда предполагается последовательный (если бы это было не так, то файл не нужен -- есть же массив), потому что набор может быть очень большим и не помещаться в оперативной памяти, а лежать на внешнем устройстве; физическое устройство этого устройства (простите за тавтологию) часто делает произвольный доступ затруднительным, как, например, на жестких дисках. Поэтому удобно хранить текущую позицию в файле того элемента данных, с которым мы работаем. Однако этот труд может взять на себя операционная система, нужно только попросить ее создать такой "индекс" текущего элемента и использовать его при чтении или записи элементов, а программисту делать этого не нужно. Именно для этого и нужно открытие файла. (Часть информации можно дать под звездочкой, но не всю, раз вообще речь заходит о курсорах.)
Далее работа с текстовыми файлами в основном превращается в работу со строками, что в целом логично, но предполагает, что отдельного текста про строки не будет? Новые функции работы со строками появляются в тексте несколько хаотично, мб, нужна некоторая систематизация (хотя бы сказать, каких типов они вообще бывают -- поиск, замена, работа с отдельными символами, с подстроками, и потом сказать, что с некоторыми мы познакомимся в задачах).
"Чаще всего открытый файл блокируется, и другие программы не могут использовать его." -- странное заявление, во-первых, это зависит от ОС, во-вторых, от режима открытия файла, я бы сказал, что чаще всего дела обстоят ровно наоборот. Лучше это вообще удалить, а рассуждения о блокировке перенести в режимы открытия файла.
Часть разговора о файловом курсоре напрашивается перенести в самое начало, где речь идет об открытии файла. Зачем вообще открывать файлы? (Это один из примеров мест, где лучше избегать появления новых понятий без объяснения). Потому что, раз файл -- это набор данных, то нам надо указать, с каким элементом набора мы хотим работать. Однако доступ к элементам почти всегда предполагается последовательный (если бы это было не так, то файл не нужен -- есть же массив), потому что набор может быть очень большим и не помещаться в оперативной памяти, а лежать на внешнем устройстве; физическое устройство этого устройства (простите за тавтологию) часто делает произвольный доступ затруднительным, как, например, на жестких дисках. Поэтому удобно хранить текущую позицию в файле того элемента данных, с которым мы работаем. Однако этот труд может взять на себя операционная система, нужно только попросить ее создать такой "индекс" текущего элемента и использовать его при чтении или записи элементов, а программисту делать этого не нужно. Именно для этого и нужно открытие файла. (Часть информации можно дать под звездочкой, но не всю, раз вообще речь заходит о курсорах.)
Далее работа с текстовыми файлами в основном превращается в работу со строками, что в целом логично, но предполагает, что отдельного текста про строки не будет? Новые функции работы со строками появляются в тексте несколько хаотично, мб, нужна некоторая систематизация (хотя бы сказать, каких типов они вообще бывают -- поиск, замена, работа с отдельными символами, с подстроками, и потом сказать, что с некоторыми мы познакомимся в задачах).
Re: Файл с текстом параграфа
1. Разделение файлов на текстовые и двоичные довольно скользкий момент, так как формально текстовые файлы можно также считать и двоичными. Чтобы быть совсем корректными, можно было бы сказать, что один и тот же файл как последовательность байтов может восприниматься по разному в зависимости от того, какой смысл мы в эти байты вкладываем. И самым распространенным "взглядом" на байты является их интерпретация как символов.
Возможно, подобные рассуждения являются слишком запутанными для школьников. Можно попробовать выразиться проще, не вводя разделение на две категории -- текстовые и бинарные -- а выделяя текстовые файлы как один из множества типов файлов. То есть файл -- это любой набор байтов, текстовый файл -- это набор байтов, кодирующих символы. Так как это очень естественный способ хранить данные в понятном для человека формате, он часто используется, поэтому мы его и рассматриваем. Можно дополнительно сказать (а можно и не говорить), что кодировать символы можно по-разному. В таком случае важно, чтобы тот, кто символы в файл записал, и тот, кто символы из файла пытается читать, использовали один и тот же способ их кодирования.
2. "В большинстве языков программирования с файлами работают через вспомогательные переменные (их называют указатели, идентификаторы и т. п.)." Я бы вместо не связанных непосредственно с файлами слов "указатель" и "идентификатор" упомянул термин "файловый дескриптор"
3. Не очень понял, почему в сноске 1 про открытие файла сказано "Еще раз ...". Вроде бы ранее упоминаний об этом я не видел. Мне кажется можно в паре предложений и без сносок честно объяснить, что вообще первый аргумент это путь к файлу, пути бывают двух видов -- абсолютный (начинающийся с некоторой начальной точки, которая зависит от операционной системы, например корневая директория в линуксе или диск в винде) и относительный (от директории, в которой находится программа). Поэтому если файл лежит в той же директории, что и программа, достаточно указать его имя.
4. В последней строке файла тоже может быть символ перевода строки. Если я правильно читаю документацию, там сказано, что символ перевода строки может отсутствовать на последней строке файла, если в файле его нет, однако если он есть, он останется. При этом эта строка все равно будет считаться последней, следующий вызов readline() вернет пустую строку.
5. Про менеджер контекста, насколько я понимаю документацию, формулировки не очень корректны. В учебника написано так, как будто менеджер контекста это with, и он сам по себе что-то делает с файлом. На самом деле, менеджер контекста это сам файловый объект, а with это оператор, в который мы можем передать любой менеджер контекста (в том числе файловый объект), и результатом его выполнения будет правильная последовательность вызовов методов этого менеджера контекста (например, close).
Я бы написал аккуратнее, что в языке питон есть специальные типы объектов, которые называются менеджерами контекста, и файловый объект -- один из них. Такие объекты могут использоваться в операторе with, который знает, какие методы таких объектов и в каком порядке нужно вызывать для корректной работы. Поэтому вместо того, чтобы самостоятельно запомнинать для каждого вида объектов, какие методы нужно вызывать и в каком порядке, можно просто использовать оператор with, в том числе и для файлов.
6. Про rstrip я бы добавил в конец пояснение, что лишняя пустая строка после каждой строки будет из-за того, что print сначала выведет перевод строки, которым оканчивается каждая строка, а потом добавит сам еще один.
7. "Открытый файл будет автоматически закрыт сразу же после выполнения этой строки, потому что временный файловый объект, созданный функцией open, не связан ни с одной переменной в программе." Кажется это неверно, файл будет закрыт тогда, когда решит сборщик мусора, что совершенно не обязательно произойдет сразу же после выполнения этой строки.
С методической точки зрения я бы вообще не стал приводить такой пример, так как он противоречит предыдущим утверждениям о том, что все файлы должны быть закрыты. По большому счету можно не закрывать ни один файл, а вместо этого дропнуть все ссылки на них. Но это плохой подход, потому что закрыты они могут быть не сразу. Так же и здесь. Нужно либо объяснить, почему этим подходом не следует злоупотреблять, либо вообще его не касаться.
8. "Для вывода в файл чисел или списка нужно преобразовать все данные в одну символьную строку, например, используя механизм f-строк:" Странно звучит, как будто нельзя сделать несколько последовательных вызовов write.
9. "Для вывода в файл удобно применять знакомую вам функцию print с дополнительным аргументом file..." Немного странно звучит, я бы добавил пояснение, что это два альтернативных способа записи текста в файл, они оба нужны для одного и того же, и можно использовать любой из них, какой удобнее. А то у меня создалось впечатление, что если мы делаем write, то обязательно нужно выводить f-строку как в примере, а если print, то через запятую, как в примере.
10. В пункте про обработку строк из файла, не очень понимаю, зачем нужен комментарий про 10^6 символов и невозможность ручной обработки из-за большого объема файла. Во-первых, ограничение на 10^6 почему-то сверху, что не гарантирует, что файл будет большим, а во-вторых, в примерах много раз встречались задачи, которые можно выполнить вручную, но это нам не мешало. Я бы убрал эти примечания целиком.
Возможно, подобные рассуждения являются слишком запутанными для школьников. Можно попробовать выразиться проще, не вводя разделение на две категории -- текстовые и бинарные -- а выделяя текстовые файлы как один из множества типов файлов. То есть файл -- это любой набор байтов, текстовый файл -- это набор байтов, кодирующих символы. Так как это очень естественный способ хранить данные в понятном для человека формате, он часто используется, поэтому мы его и рассматриваем. Можно дополнительно сказать (а можно и не говорить), что кодировать символы можно по-разному. В таком случае важно, чтобы тот, кто символы в файл записал, и тот, кто символы из файла пытается читать, использовали один и тот же способ их кодирования.
2. "В большинстве языков программирования с файлами работают через вспомогательные переменные (их называют указатели, идентификаторы и т. п.)." Я бы вместо не связанных непосредственно с файлами слов "указатель" и "идентификатор" упомянул термин "файловый дескриптор"
3. Не очень понял, почему в сноске 1 про открытие файла сказано "Еще раз ...". Вроде бы ранее упоминаний об этом я не видел. Мне кажется можно в паре предложений и без сносок честно объяснить, что вообще первый аргумент это путь к файлу, пути бывают двух видов -- абсолютный (начинающийся с некоторой начальной точки, которая зависит от операционной системы, например корневая директория в линуксе или диск в винде) и относительный (от директории, в которой находится программа). Поэтому если файл лежит в той же директории, что и программа, достаточно указать его имя.
4. В последней строке файла тоже может быть символ перевода строки. Если я правильно читаю документацию, там сказано, что символ перевода строки может отсутствовать на последней строке файла, если в файле его нет, однако если он есть, он останется. При этом эта строка все равно будет считаться последней, следующий вызов readline() вернет пустую строку.
5. Про менеджер контекста, насколько я понимаю документацию, формулировки не очень корректны. В учебника написано так, как будто менеджер контекста это with, и он сам по себе что-то делает с файлом. На самом деле, менеджер контекста это сам файловый объект, а with это оператор, в который мы можем передать любой менеджер контекста (в том числе файловый объект), и результатом его выполнения будет правильная последовательность вызовов методов этого менеджера контекста (например, close).
Я бы написал аккуратнее, что в языке питон есть специальные типы объектов, которые называются менеджерами контекста, и файловый объект -- один из них. Такие объекты могут использоваться в операторе with, который знает, какие методы таких объектов и в каком порядке нужно вызывать для корректной работы. Поэтому вместо того, чтобы самостоятельно запомнинать для каждого вида объектов, какие методы нужно вызывать и в каком порядке, можно просто использовать оператор with, в том числе и для файлов.
6. Про rstrip я бы добавил в конец пояснение, что лишняя пустая строка после каждой строки будет из-за того, что print сначала выведет перевод строки, которым оканчивается каждая строка, а потом добавит сам еще один.
7. "Открытый файл будет автоматически закрыт сразу же после выполнения этой строки, потому что временный файловый объект, созданный функцией open, не связан ни с одной переменной в программе." Кажется это неверно, файл будет закрыт тогда, когда решит сборщик мусора, что совершенно не обязательно произойдет сразу же после выполнения этой строки.
С методической точки зрения я бы вообще не стал приводить такой пример, так как он противоречит предыдущим утверждениям о том, что все файлы должны быть закрыты. По большому счету можно не закрывать ни один файл, а вместо этого дропнуть все ссылки на них. Но это плохой подход, потому что закрыты они могут быть не сразу. Так же и здесь. Нужно либо объяснить, почему этим подходом не следует злоупотреблять, либо вообще его не касаться.
8. "Для вывода в файл чисел или списка нужно преобразовать все данные в одну символьную строку, например, используя механизм f-строк:" Странно звучит, как будто нельзя сделать несколько последовательных вызовов write.
9. "Для вывода в файл удобно применять знакомую вам функцию print с дополнительным аргументом file..." Немного странно звучит, я бы добавил пояснение, что это два альтернативных способа записи текста в файл, они оба нужны для одного и того же, и можно использовать любой из них, какой удобнее. А то у меня создалось впечатление, что если мы делаем write, то обязательно нужно выводить f-строку как в примере, а если print, то через запятую, как в примере.
10. В пункте про обработку строк из файла, не очень понимаю, зачем нужен комментарий про 10^6 символов и невозможность ручной обработки из-за большого объема файла. Во-первых, ограничение на 10^6 почему-то сверху, что не гарантирует, что файл будет большим, а во-вторых, в примерах много раз встречались задачи, которые можно выполнить вручную, но это нам не мешало. Я бы убрал эти примечания целиком.
Re: Файл с текстом параграфа
Какие ещё могут быть?nikolay wrote: Tue Jun 16, 2026 7:23 am 1. Фразу «из всех специальных символов в текстовых файлах могут быть только символы перехода на новую строку» возможно стоит смягчить до «как правило, кроме символов перехода на новую строку специальные символы в таких файлах не используются»?
Переписал:nikolay wrote: Tue Jun 16, 2026 7:23 am 2. Текстовый файл – это "устройство" последовательного доступа…» - возможно слово устройство лучше заменить на что-то типа «объект последовательного доступа» или «структура данных, к которой осуществляется последовательный доступ»?
"Как правило, текстовый файл обеспечивает последовательный доступ к данным."
Re: Файл с текстом параграфа
Я немного частично повторюсь за коллегами, но немного со своими акцентами.
1. Кажется, всё-таки речи про строковые значения до этого не было. Или, прошу прощения, я где-то проглядел. Возможно, это уместно сделать там, где говорится про типы данных - например, чтобы подчеркнуть, что '2' и 2 (а для Си было бы ещё и "2") - это разные сущности, закодированные по-разному (с этим, по моему опыту, у части школьников трудности вплоть до 11 класса, даже если объясняли раньше), а операция сложения для строк, если поддерживается, то означает традиционно принципиально иную вещь (конкатенацию), нежели для чисел.
2. Насколько я понимаю смысл упоминания "спецсимволов" по контексту - тут важнее мысль, что они вообще есть, чтобы появился повод упомянуть символ перехода на новую строчку, важный для дальнейшего изложения. Мне кажется, это, скорее, вопрос больше относящийся к строкам и к способу их кодирования в языках - и тут могло бы смысл излагать наоборот: что помимо "нормальных" символов, для которых есть изображение, и спец.символов, некоторые из которых играют управляющую роль, и одним из которых является символ перехода на новую строчку -- и такие "ненормальные" символы в тексте программы приходится кодировать сочетаниями символов - например, с использованием так называющего "экранирующего" символа, который сам в таком случае становится специальным с точки зрения записи значений. (Возможно, это есть в курсе более ранних классов, но можно и повторить для закрепления - с этим у школьников тоже традиционная забывчивость.)
3. Вероятно, заслуживает отдельного абзаца терминологическая путаница, связанная со употреблением слова "строка" в русском языке, которое может означать и строчку текста, расположенного "на одной линии" (line), и строку как тип данных для представления текста как цепочки символов (string).
4. К перечислению про "указатели, файловые объекты, ..." помимо предложенных дескрипторов я бы добавил и термин "файловый поток" (с пояснением stream)- ибо во многих языках используется именно этот термин... даже в стандарте Си значения FILE* описываются словом stream (и само название`FILE` в некотором смысле не вполне удачное).
5. Термин "файловый объект" может быть немного дезориентирующим, так как в каких-то библиотеках некоторых языков "файловый объект" - это, скорее, нечто, описывающее элемент файловой системы и манипуляцию его свойствами, но не процессом чтения-записи. Для себя я пока остановился на том, что со своими школьниками использую всё-таки термин "файловый поток", поясняя, что это объект, позволяющий следить за состоянием процесса чтения или записи в файл, с которым связаны и некоторые ресурсы операционной системы (в частности и поэтому лучше их вовремя закрывать - хотя, признаюсь, важность упоминания этого - это уже некоторая профдеформация, связанная с проф. областью, хехе). Смысл термина "поток" я поясняю "на пальцах", что эффективно поддерживается именно последовательный ("поточный") доступ.
1. Кажется, всё-таки речи про строковые значения до этого не было. Или, прошу прощения, я где-то проглядел. Возможно, это уместно сделать там, где говорится про типы данных - например, чтобы подчеркнуть, что '2' и 2 (а для Си было бы ещё и "2") - это разные сущности, закодированные по-разному (с этим, по моему опыту, у части школьников трудности вплоть до 11 класса, даже если объясняли раньше), а операция сложения для строк, если поддерживается, то означает традиционно принципиально иную вещь (конкатенацию), нежели для чисел.
2. Насколько я понимаю смысл упоминания "спецсимволов" по контексту - тут важнее мысль, что они вообще есть, чтобы появился повод упомянуть символ перехода на новую строчку, важный для дальнейшего изложения. Мне кажется, это, скорее, вопрос больше относящийся к строкам и к способу их кодирования в языках - и тут могло бы смысл излагать наоборот: что помимо "нормальных" символов, для которых есть изображение, и спец.символов, некоторые из которых играют управляющую роль, и одним из которых является символ перехода на новую строчку -- и такие "ненормальные" символы в тексте программы приходится кодировать сочетаниями символов - например, с использованием так называющего "экранирующего" символа, который сам в таком случае становится специальным с точки зрения записи значений. (Возможно, это есть в курсе более ранних классов, но можно и повторить для закрепления - с этим у школьников тоже традиционная забывчивость.)
3. Вероятно, заслуживает отдельного абзаца терминологическая путаница, связанная со употреблением слова "строка" в русском языке, которое может означать и строчку текста, расположенного "на одной линии" (line), и строку как тип данных для представления текста как цепочки символов (string).
4. К перечислению про "указатели, файловые объекты, ..." помимо предложенных дескрипторов я бы добавил и термин "файловый поток" (с пояснением stream)- ибо во многих языках используется именно этот термин... даже в стандарте Си значения FILE* описываются словом stream (и само название`FILE` в некотором смысле не вполне удачное).
5. Термин "файловый объект" может быть немного дезориентирующим, так как в каких-то библиотеках некоторых языков "файловый объект" - это, скорее, нечто, описывающее элемент файловой системы и манипуляцию его свойствами, но не процессом чтения-записи. Для себя я пока остановился на том, что со своими школьниками использую всё-таки термин "файловый поток", поясняя, что это объект, позволяющий следить за состоянием процесса чтения или записи в файл, с которым связаны и некоторые ресурсы операционной системы (в частности и поэтому лучше их вовремя закрывать - хотя, признаюсь, важность упоминания этого - это уже некоторая профдеформация, связанная с проф. областью, хехе). Смысл термина "поток" я поясняю "на пальцах", что эффективно поддерживается именно последовательный ("поточный") доступ.
Last edited by volkov on Thu Jun 18, 2026 3:59 pm, edited 1 time in total.
Alexander Volkov
Re: Файл с текстом параграфа
Как минимум, символ табуляции - который может встречаться как символ файла с текстом программы.
Alexander Volkov
Re: Файл с текстом параграфа
Очень хорошая мысль, спасибо. Я переписал текст. Но все-таки сказал про двоичные файлы.Neket wrote: Wed Jun 17, 2026 2:59 pm 1. Разделение файлов на текстовые и двоичные довольно скользкий момент, так как формально текстовые файлы можно также считать и двоичными. Чтобы быть совсем корректными, можно было бы сказать, что один и тот же файл как последовательность байтов может восприниматься по разному в зависимости от того, какой смысл мы в эти байты вкладываем. И самым распространенным "взглядом" на байты является их интерпретация как символов.
Возможно, подобные рассуждения являются слишком запутанными для школьников. Можно попробовать выразиться проще, не вводя разделение на две категории -- текстовые и бинарные -- а выделяя текстовые файлы как один из множества типов файлов. То есть файл -- это любой набор байтов, текстовый файл -- это набор байтов, кодирующих символы. Так как это очень естественный способ хранить данные в понятном для человека формате, он часто используется, поэтому мы его и рассматриваем. Можно дополнительно сказать (а можно и не говорить), что кодировать символы можно по-разному. В таком случае важно, чтобы тот, кто символы в файл записал, и тот, кто символы из файла пытается читать, использовали один и тот же способ их кодирования.
Исправил.Neket wrote: Wed Jun 17, 2026 2:59 pm 2. "В большинстве языков программирования с файлами работают через вспомогательные переменные (их называют указатели, идентификаторы и т. п.)." Я бы вместо не связанных непосредственно с файлами слов "указатель" и "идентификатор" упомянул термин "файловый дескриптор"
Исправил.Neket wrote: Wed Jun 17, 2026 2:59 pm 3. Не очень понял, почему в сноске 1 про открытие файла сказано "Еще раз ...". Вроде бы ранее упоминаний об этом я не видел. Мне кажется можно в паре предложений и без сносок честно объяснить, что вообще первый аргумент это путь к файлу, пути бывают двух видов -- абсолютный (начинающийся с некоторой начальной точки, которая зависит от операционной системы, например корневая директория в линуксе или диск в винде) и относительный (от директории, в которой находится программа). Поэтому если файл лежит в той же директории, что и программа, достаточно указать его имя.
Если в последней строке есть \n, то перебор for s in f прочитает еще одну пустую строку. Проверил экспериментально.Neket wrote: Wed Jun 17, 2026 2:59 pm 4. В последней строке файла тоже может быть символ перевода строки. Если я правильно читаю документацию, там сказано, что символ перевода строки может отсутствовать на последней строке файла, если в файле его нет, однако если он есть, он останется. При этом эта строка все равно будет считаться последней, следующий вызов readline() вернет пустую строку.
Да, Вы правы. Исправлено.Neket wrote: Wed Jun 17, 2026 2:59 pm 5. Про менеджер контекста, насколько я понимаю документацию, формулировки не очень корректны. В учебника написано так, как будто менеджер контекста это with, и он сам по себе что-то делает с файлом. На самом деле, менеджер контекста это сам файловый объект, а with это оператор, в который мы можем передать любой менеджер контекста (в том числе файловый объект), и результатом его выполнения будет правильная последовательность вызовов методов этого менеджера контекста (например, close).
Я бы написал аккуратнее, что в языке питон есть специальные типы объектов, которые называются менеджерами контекста, и файловый объект -- один из них. Такие объекты могут использоваться в операторе with, который знает, какие методы таких объектов и в каком порядке нужно вызывать для корректной работы. Поэтому вместо того, чтобы самостоятельно запомнинать для каждого вида объектов, какие методы нужно вызывать и в каком порядке, можно просто использовать оператор with, в том числе и для файлов.
Добавил.Neket wrote: Wed Jun 17, 2026 2:59 pm 6. Про rstrip я бы добавил в конец пояснение, что лишняя пустая строка после каждой строки будет из-за того, что print сначала выведет перевод строки, которым оканчивается каждая строка, а потом добавит сам еще один.
Исправил.Neket wrote: Wed Jun 17, 2026 2:59 pm 7. "Открытый файл будет автоматически закрыт сразу же после выполнения этой строки, потому что временный файловый объект, созданный функцией open, не связан ни с одной переменной в программе." Кажется это неверно, файл будет закрыт тогда, когда решит сборщик мусора, что совершенно не обязательно произойдет сразу же после выполнения этой строки.
Не злоупотреблять.Neket wrote: Wed Jun 17, 2026 2:59 pm С методической точки зрения я бы вообще не стал приводить такой пример, так как он противоречит предыдущим утверждениям о том, что все файлы должны быть закрыты. По большому счету можно не закрывать ни один файл, а вместо этого дропнуть все ссылки на них. Но это плохой подход, потому что закрыты они могут быть не сразу. Так же и здесь. Нужно либо объяснить, почему этим подходом не следует злоупотреблять, либо вообще его не касаться.
Исправлено.Neket wrote: Wed Jun 17, 2026 2:59 pm 8. "Для вывода в файл чисел или списка нужно преобразовать все данные в одну символьную строку, например, используя механизм f-строк:" Странно звучит, как будто нельзя сделать несколько последовательных вызовов write.
Исправлено.Neket wrote: Wed Jun 17, 2026 2:59 pm 9. "Для вывода в файл удобно применять знакомую вам функцию print с дополнительным аргументом file..." Немного странно звучит, я бы добавил пояснение, что это два альтернативных способа записи текста в файл, они оба нужны для одного и того же, и можно использовать любой из них, какой удобнее. А то у меня создалось впечатление, что если мы делаем write, то обязательно нужно выводить f-строку как в примере, а если print, то через запятую, как в примере.
Убрал.Neket wrote: Wed Jun 17, 2026 2:59 pm 10. В пункте про обработку строк из файла, не очень понимаю, зачем нужен комментарий про 10^6 символов и невозможность ручной обработки из-за большого объема файла. Во-первых, ограничение на 10^6 почему-то сверху, что не гарантирует, что файл будет большим, а во-вторых, в примерах много раз встречались задачи, которые можно выполнить вручную, но это нам не мешало. Я бы убрал эти примечания целиком.
Спасибо за замечания.
Re: Файл с текстом параграфа
Напрямую относящиеся к тексту -- табуляция, возврат каретки. Формально и другие можно записать.