Краткий ответ

Параметр объявляют только позиционным, чтобы его значение можно было передать лишь по позиции, а имя параметра не становилось частью публичного API. Это позволяет позднее переименовать внутренний параметр без поломки вызовов, использующих позиционную передачу.

Исторический контекст

В Python долго существовали функции, особенно встроенные и реализованные на C, чьи аргументы фактически принимались только позиционно. Явный синтаксис для описания такого интерфейса появился в Python 3.8 и стандартизировал возможность выражать это ограничение непосредственно в определении функции.

Исходная проблема состояла в том, что имя параметра могло случайно превратиться в обязательную часть API. Если пользователи начинают передавать аргумент по имени, его переименование становится обратно несовместимым изменением.

Постановка проблемы

Представим публичную функцию, у которой первый параметр внутри реализации называется source. Если пользователи вызывают её с именованным аргументом, это имя закрепляется во внешнем контракте. Позднее переименование параметра в input_data может привести к ошибкам у уже существующих клиентов.

Полный запрет именованной передачи тоже имеет цену: вызовы становятся менее самодокументируемыми, а порядок аргументов нужно знать заранее. Поэтому позиционными делают только те параметры, для которых имя не должно быть частью API.

Подробное решение

Символ / в сигнатуре отделяет позиционно-ориентированные параметры от остальных. При связывании аргументов Python разрешает таким параметрам получать значения только из позиционных аргументов; попытка передать их по имени вызывает TypeError ещё до выполнения тела функции.

def open_record(path, mode="r", /):
    return path, mode

open_record("data.txt", "rb")       # допустимо
# open_record("data.txt", mode="rb") # TypeError

Внутри функции параметры по-прежнему доступны по своим локальным именам. Ограничение действует только на способ вызова, а не на использование переменной в теле функции.

Главное преимущество — защита от случайного расширения API. Реализация может переименовать path или mode, не ломая корректные позиционные вызовы. Это также полезно, когда имя параметра может конфликтовать с ключами, передаваемыми через **kwargs, либо когда библиотека хочет сохранить свободу изменения внутренней терминологии.

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

Ситуация из практики

Команда разрабатывает библиотеку обработки документов. Функция принимает путь к документу и формат чтения, причём эти параметры являются базовой частью операции, а библиотека планирует менять внутренние названия переменных.

Рассматривались три варианта. Обычные параметры сохраняли максимальную гибкость, но позволяли клиентам закрепить внутренние имена через именованные вызовы. Полностью позиционная функция защищала имена, но ухудшала читаемость всех аргументов. Использование позиционных параметров только для базовых аргументов сохранило компактный вызов и не связало публичный контракт с названиями внутри реализации.

Выбран был третий вариант: обязательные базовые параметры сделали позиционными, а редко используемые параметры оставили доступными по имени. В результате внутренние параметры можно переименовывать без изменения корректных клиентских вызовов, а дополнительные настройки остаются понятными в месте использования.

Что кандидаты часто упускают

Доступен ли позиционно-ориентированный параметр по имени внутри тела функции?

Да. Ограничение относится только к передаче аргумента вызывающим кодом. После связывания аргументов параметр становится обычным локальным именем функции, поэтому его можно читать, изменять или передавать другим вызовам.

Можно ли у позиционно-ориентированного параметра указать значение по умолчанию?

Да. Позиционный режим и наличие значения по умолчанию — независимые свойства. Такой параметр можно не передавать, если Python может использовать значение по умолчанию, но если он передан, передать его разрешено только позиционно.

Что произойдёт при передаче такого параметра через словарь распакованных именованных аргументов?

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