Зачастую сложнее удалить опциональный аргумент (и логику внутри функции), который был добавлен на всякий случай и, казалось бы, никогда не используется, чем ввести новый необязательный аргумент и его логику в тот момент, когда они действительно нужны.

• Список с произвольным количеством аргументов. Такой список определяется с помощью конструкции *args, которая указывает на произвольное количество позиционных аргументов. В теле функции args будет играть роль кортежа, состоящего из всех оставшихся позиционных аргументов. Например, функция send(message, *args) также может быть вызвана, когда каждый получатель будет представлен отдельным аргументом: send("42", "Frankie", "Benjy", "Trillian"). В теле функции конструкция args будет равна выражению ("Frankie", "Benjy", "Trillian"). Хороший пример, иллюстрирующий этот подход, — функция print.

Подводный камень: если функция получает список аргументов одного вида, более понятным будет использование списка или любой другой последовательности. Если функция send в этом примере принимает несколько получателей, мы определим ее явно как send(message, recipients) и будем вызывать как send("42", ["Benjy", "Frankie", "Trillian"]).

• Словарь с произвольным количеством аргументов с ключевым словом. Такой словарь определяется с помощью конструкции **kwargs, которая указывает на произвольное количество именованных аргументов. В теле функции kwargs будет словарем, содержащим все переданные именованные аргументы, которые не были «пойманы» другими аргументами с ключевым словом в сигнатуре функции. Это может быть полезно при журналировании. Средства форматирования на разных уровнях могут принять необходимую им информацию, минуя пользователя.

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

Имена переменных args и *kwargs могут (и должны быть) заменены другими, если это более информативно.

Какие аргументы станут позиционными, а какие — необязательными, зависит только от программиста, который пишет функцию. От него также зависит наличие передачи произвольного количества аргументов. В конце концов, должен существовать один (предпочтительно всего один) очевидный способ это сделать. Другие пользователи оценят ваши усилия, если функции, написанные на Python: • легко прочитать (имя и аргументы не требуют объяснения);

• легко изменить (добавление нового аргумента с ключевым словом не разрушит другие части кода).

Если реализацию сложно объяснить — идея плоха

Python поставляется с богатым набором инструментов (за что его любят хакеры), который позволяет вам делать абсолютно невероятные вещи, например: • изменять способ создания объектов;

• изменять способ импортирования модулей Python;

• встраивать в Python подпрограммы, написанные на С.

Все эти действия имеют недостатки, поэтому всегда лучше выбирать прямолинейный способ достижения цели. Основной минус: при использовании подобных конструкций снижается читаемость, поэтому то, что вы получаете в результате, должно быть более важным, чем потеря читаемости. Многие инструменты, предназначенные для анализа кода, не смогут работать с таким «волшебным» кодом.

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

Как и мастера кун-фу, питонисты знают, как можно убить одним пальцем, и никогда этого не делают.

Мы все — ответственные пользователи

Как уже демонстрировалось, с помощью Python можно делать многое, но некоторые приемы потенциально могут быть опасными. В частности, любой клиентский код может переопределить свойства и методы объекта: в Python нет ключевого слова private. Эта философия сильно отличается от той, что присуща высокозащищенным языкам вроде Java, — они имеют множество механизмов, предотвращающих неверное использование. Философия Python сосредоточена во фразе «Мы все — ответственные пользователи».

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

Основным соглашением для закрытых свойств и деталей реализации является добавление к именам всех подобных элементов нижнего подчеркивания (например, sys._getframe). Если клиентский код нарушает это правило и получает доступ к отмеченным элементам, будет считаться, что любое неверное поведение или проб­лемы вызваны именно клиентским кодом.

Перейти на страницу:

Поиск

Похожие книги