Эмпирические правила, когда использовать перегрузку операторов в Python

Перегрузка оператора в основном полезна, когда вы создаете новый класс, который попадает в существующий «абстрактный базовый класс» (ABC) - действительно, многие из ABC в стандартном библиотечном модуле collections полагаются на наличие определенных специальных методов (и специальных методов, имена которых начинаются и заканчиваются двойным подчеркиванием AKA" dunders " , точно так же, как вы выполняете перегрузку операторов в Python). Это дает хорошее руководство по запуску.

Например, класс Container должен переопределить специальный метод __contains__, т. Е. Оператор проверки членства item in container (например, if item in container: - не путайте с оператором for, for item in container:, который полагается на _7 _! - ). Точно так же Hashable должен переопределять __hash__, Sized должен переопределять __len__, Sequence или Mapping должен переопределять __getitem__ и так далее. (Более того, ABC могут предоставить вашему классу функции микширования - например, как Sequence, так и Mapping могут предоставить __contains__ на основе предоставленного вами переопределения __getitem__ и, таким образом, автоматически сделать ваш класс Container).

Помимо collections, вы захотите переопределить специальные методы (т.е. предусмотреть перегрузку оператора) в основном, если ваш новый класс «является числом». Существуют и другие особые случаи, но не поддавайтесь искушению перегрузить операторы «просто для прохлады», без семантической связи с «нормальными» значениями, как потоки C ++ для << и >> и строк Python (в Python 2.*, к счастью, не в 3.* any подробнее ;-) сделать для % - когда такие операторы больше не означают «сдвиг битов» или «остаток от деления», вы просто вносите путаницу. Стандартная библиотека языка может сойти с рук (хотя и не должна ;-), но если ваша библиотека не получит такого же широкого распространения, как стандартная библиотека языка, путаница повредит! -)

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

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

Поэтому, если вы создаете новый класс RomanNumeral, имеет смысл перегрузить сложение и вычитание и т. Д. Но не перегружайте его, если это не является естественным: нет смысла определять сложение и вычитание для объекта Car или Vehicle.

Еще одно практическое правило: не перегружайте ==. Из-за этого очень сложно (хотя и возможно) проверить, являются ли два объекта одинаковыми. Я допустил эту ошибку и долго расплачивался за нее.

Что касается того, когда перегружать +=, ++ и т. Д., Я бы сказал: перегружайте только дополнительные операторы, если у вас есть большой спрос на эту функциональность. Легче иметь один способ сделать что-то, чем пять. Конечно, это означает, что иногда вам придется писать x = x + 1 вместо x += 1, но можно и больше кода, если он будет понятнее.

В общем, как и в случае со многими «причудливыми» функциями, легко подумать, что вы чего-то хотите, хотя на самом деле вы этого не делаете, реализуете кучу вещей, не замечаете побочных эффектов, а потом выясняете это позже. Заблуждайтесь с консервативной стороны.

РЕДАКТИРОВАТЬ: Я хотел добавить пояснительную записку о перегрузке ==, потому что кажется, что разные комментаторы неправильно это понимают, и это меня поймало. Да, is существует, но это другая операция. Скажем, у меня есть объект x, который либо из моего настраиваемого класса, либо является целым числом. Я хочу проверить, является ли x числом 500. Но если вы установите x = 500, а затем протестируете x is 500, вы получите False из-за того, как Python кэширует числа. С 50 он вернет True. Но вы не можете использовать is, потому что вы можете захотеть, чтобы x == 500 возвращал True, если x является экземпляром вашего класса. Сбивает с толку? Определенно. Но это то, что вам нужно знать, чтобы успешно перегрузить операторы.

Вот пример, в котором используется побитовая операция or для имитации конвейера unix. Это задумано как противоположный пример большинству практических правил.

Я только что нашел Lumberjack, который использует этот синтаксис в реальном коде.

class pipely(object):
    def __init__(self, *args, **kw):
        self._args = args
        self.__dict__.update(kw)

    def __ror__(self, other):
        return ( self.map(x) for x in other if self.filter(x) )

    def map(self, x):
        return x

    def filter(self, x):
        return True

class sieve(pipely):
    def filter(self, x):
        n = self._args[0]
        return x==n or x%n

class strify(pipely):
    def map(self, x):
        return str(x)

class startswith(pipely):
    def filter(self, x):
        n=str(self._args[0])
        if x.startswith(n):
            return x

print"*"*80
for i in xrange(2,100) | sieve(2) | sieve(3) | sieve(5) | sieve(7) | strify() | startswith(5):
    print i

print"*"*80
for i in xrange(2,100) | sieve(2) | sieve(3) | sieve(5) | sieve(7) | pipely(map=str) | startswith(5):
    print i

print"*"*80
for i in xrange(2,100) | sieve(2) | sieve(3) | sieve(5) | sieve(7) | pipely(map=str) | pipely(filter=lambda x: x.startswith('5')):
    print i

Перегрузка в Python в целом «безопаснее», чем в C ++ - например, оператор присваивания не может быть перегружен, а += имеет разумную реализацию по умолчанию.

Однако в некотором смысле перегрузка в Python все еще так же «сломана», как и в C ++. Программисты должны сдерживать желание «повторно использовать» оператор для несвязанных целей, таких как повторное использование битовых сдвигов в C ++ для выполнения форматирования и синтаксического анализа строк. Не перегружайте оператор семантикой, отличной от вашей реализации, только для того, чтобы получить более красивый синтаксис.

Современный стиль Python категорически не поощряет «мошенническую» перегрузку, но многие аспекты языка и стандартной библиотеки сохраняют плохо названные операторы для обратной совместимости. Например:

• %: модуль и форматирование строки
• +: сложение и конкатенация последовательностей
• *: умножение и повторение последовательности

Итак, практическое правило? Если ваша реализация оператора удивит людей, не делайте этого.