Стандартная библиотека и строки

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 14, остальные разбираются в тренажёре.

1. #stdlib_strings1 / 5
   Зачем использовать enumerate и zip вместо range(len(...)) с индексацией?

   A)Они переводят коллекцию в строку и обратно, что зачем-то необходимо для корректного прохода по её элементам в цикле for

   B)Они предварительно сортируют коллекцию, поэтому цикл по enumerate идёт в возрастающем порядке элементов

   C)enumerate даёт пары (индекс, элемент), zip идёт по нескольким коллекциям параллельно — читаемее и без ошибок с индексами

   D)Они кешируют длину коллекции, за счёт чего цикл по ним оказывается в разы быстрее другого способа её обхода в Python

   показать ответ и разбор

   +C)enumerate даёт пары (индекс, элемент), zip идёт по нескольким коллекциям параллельно — читаемее и без ошибок с индексами

   // разбор: enumerate(xs) отдаёт пары (i, x), избавляя от range(len(xs)) и ручного xs[i]; zip(a, b) идёт по нескольким последовательностям сразу, останавливаясь на самой короткой. Это читаемее, короче и не порождает классических ошибок с выходом за границы и рассинхроном индексов. Сортировки и особого ускорения тут нет.

2. #stdlib_strings2 / 5
   Чем f-строки обычно предпочтительнее конкатенации через + и %-форматирования?

   A)F-строки вычисляются на этапе компиляции и поэтому запрещают вставлять внутрь себя изменяемые переменные

   B)Ничем: f-строки — устаревший синтаксис, а современный рекомендованный способ форматирования — это оператор % с круглыми скобками

   C)F-строки работают лишь с числами и не дают подставить внутрь фигурных скобок строку или результат вызова метода

   D)Читаемее и обычно быстрее: выражение прямо в {…}, сразу видно, что куда подставляется; + требует ручных приведений, % легко сбить

   показать ответ и разбор

   +D)Читаемее и обычно быстрее: выражение прямо в {…}, сразу видно, что куда подставляется; + требует ручных приведений, % легко сбить

   // разбор: f-строка f'{name}: {price*qty:.2f}' подставляет выражения прямо по месту — читается сверху вниз, поддерживает форматные спецификаторы и обычно быстрее .format и %. Конкатенация через + требует ручного приведения типов и легко путается, а %-стиль легко рассинхронизировать по позициям аргументов. Отсюда f-строки как способ по умолчанию.

3. #stdlib_strings3 / 5
   Нужно посчитать, сколько раз каждый элемент встречается в списке. Идиоматичный инструмент?

   A)Отсортировать список и вручную пройтись циклом, наращивая счётчик и сбрасывая его при каждой смене соседнего значения в проходе

   B)collections.Counter(список): считает частоты за один проход, а его метод most_common(k) сразу отдаёт k самых частых элементов

   C)Создать обычный список нулей длиной со словарь и вручную инкрементировать индексы, соответствующие каждому встреченному элементу

   D)Множество set(список): оно само хранит, сколько раз каждый элемент был в него добавлен, и отдаёт это по запросу количества

   показать ответ и разбор

   +B)collections.Counter(список): считает частоты за один проход, а его метод most_common(k) сразу отдаёт k самых частых элементов

   // разбор: Counter из collections принимает итерируемое и возвращает подсчёт {элемент: частота} за один проход, а его метод most_common(k) сразу выдаёт k самых частых. Ручные варианты через сортировку или ручной словарь-счётчик многословнее и легче ошибиться, а set хранит только уникальные элементы, без счётчиков.

4. #stdlib_strings4 / 5
   Чем pathlib.Path лучше склейки путей строками через '/' или '+'?

   A)Ничем: ручная конкатенация путей строкой через плюс — рекомендованный и самый переносимый способ работы с файловой системой

   B)Pathlib работает в основном в Linux, поэтому в кроссплатформенном коде его применение не рекомендуется

   C)Кроссплатформенный разделитель, склейка оператором / и методы (.exists, .suffix, .parent) вместо хрупкой ручной возни со строками

   D)Pathlib при обращении к объекту Path автоматически создаёт на диске все несуществующие директории из этого пути без спроса

   показать ответ и разбор

   +C)Кроссплатформенный разделитель, склейка оператором / и методы (.exists, .suffix, .parent) вместо хрупкой ручной возни со строками

   // разбор: Path сам подставляет правильный разделитель под ОС, склеивается оператором / — Path('dir') / 'file.txt' — и даёт удобные методы и свойства: .exists(), .parent, .suffix, .name, .read_text(). Это надёжнее хрупких строковых манипуляций и os.path.join. Директории Path сам не создаёт — для этого есть явный .mkdir().

5. #stdlib_strings5 / 5
   В чём разница между str и bytes в Python 3 и зачем нужны encode/decode?

   A)Str и bytes — это полные синонимы в Python 3, а методы encode/decode оставлены в языке лишь для совместимости со старым кодом на Python 2

   B)str — последовательность символов Unicode, bytes — сырые байты; encode (str→bytes) и decode (bytes→str) переводят между ними по кодировке

   C)Bytes хранит внутри себя ASCII-символы, а str — цифры; для иных данных оба типа непригодны

   D)Разница между ними в скорости работы: bytes ощутимо быстрее str, а по смыслу это один и тот же тип данных

   показать ответ и разбор

   +B)str — последовательность символов Unicode, bytes — сырые байты; encode (str→bytes) и decode (bytes→str) переводят между ними по кодировке

   // разбор: В Python 3 str — это текст (последовательность Unicode-символов), а bytes — сырые байты (например, из файла или сети). Между ними переводят явно: str.encode(кодировка) даёт bytes (в UTF-8 «é» → 2 байта, проверено), bytes.decode(кодировка) — обратно в str. Смешивать их нельзя, а неверная кодировка при decode ломается или портит текст. Это не синонимы и не «только про скорость»; путаница str/bytes — источник UnicodeDecodeError.