Руководство по магическим методам в Питоне

[@mibori]

мне очень нравится питон синтаксисом, но именование ______________name_____________ выглядит просто вырвиглазно.

хотя, наверное, для питонщиков, это стало привычкой.

[@ffriend]

Ну, во-первых, подчёркивания там максимум по 2 с каждой стороны, что вполне читаемо. А во-вторых, сравните это с кучей ключевых слов и специального синтаксиса типа private, operator, Constructor() и т.д. в других языках ;)

[@mibori]

Читаемо, не спорю. Но не красиво. Вырывается из стиля :-)

class, def, return, except, print — присуствуют и смотрятся ведь красиво. Так что нет ничего страшного в ключевых словах, кроме их количества.

Давайте пофантазируем.

from os.path import join

class FileObject:
    def __init__(self, filepath='~', filename='sample.txt'):
        self.file = open(join(filepath, filename), 'r+')

    def __del__(self):
        self.file.close()
        del self.file

например в

from os.path import join

class FileObject:
    def init.core(self, filepath = '~', filename = 'sample.txt'):
        self.file = open(join(filepath, filename), 'r+')

    def del.core(self):
        self.file.close()
        del self.file

согласитесь, выглядет по-гламурнее? :-) (надеюсь в существующем питоне нет возможнсти def parent.child(args))

[@kmike]

Пара минусов del.core/init.core по сравнению с __del__/__init__:

1) del.core читается «удалить ядро», init.core — «инициализировать ядро». В __del__ таких лишних смыслов нет.
2) в синтаксис языка добавляется новая сущность — точка в объявлении метода. Это усложнение, которое, к тому же, ко всяким неоднозначностям ведет:

class Foo:
    def core(self):
        print('Foo')

class FileObject:
    def del.core(self):
        print('FileObject')

    def del(self):
        return Foo()

и теперь вызываем file_object.del.core() — что будет напечатано?

__магические__ методы решают вполне осязаемые практические проблемы простым (и imho красивым) способом, зачем что-то усложнять? Переименование __next__ в next.core никаких практических проблем не решает.

[@mibori]

согласен с вашими аргументами, ниже ответил anjensan.

[@anjensan]

Ваш вариат не работает. Вызвать x.__init__(x) можно, а вот x.init.core(x) — уже нет, нету способа отличить это от 2х независимых вызовов.

На самом деле, это достаточно распространенная практика во многих языках — использовать знак(и) подчеркивания для обозначения приватных или «магических» вещей. Могли бы конечно выделять специальные методы только с одной стороны (было бы __init, __del и т.д.). Но это, на мой взгляд, менее красиво, да и выделение с одной стороны уже используется для name mangling.

Попробуйте предложить рабочую альтертаниву такому решению. Уверен, что однозначного «победителя» не найдется.

[@mibori]

Что ж, у вас железные аргументы. Асло, "__" мне не нравится и в других языках. Исключая бинарные операции, программирование символами псевдографики — это истинное брэйнфакство. Архаизм. Имхоу. От этого не уйдешь, потому что удобно, но "__" в именах — злоупотребление, мне кажется.

На счет рабочих вариантов — не приходит на ум ничего оригинального.
Mожет быть x.magic.init(x) и def magic.init(x):. «magic» — неймспейс для доступа к магии.

[@ffriend]

Исключая бинарные операции, программирование символами псевдографики — это истинное брэйнфакство.

* — вместо «всё»
import com.package.*
[] — для обращения к элементам массива
items[5]
= — для обозначения присваивания:
x = 1
ну и т.д.

Что касается конкретно символов подчёркивания в имени, чем они хуже точки или CamelCase? Это вопрос привычки, и когда привыкаете, понимаете, что это действительно удобно, и вы уже не хотите ничего другого.

[@leventov]

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

[@kmike]

Вырвиглазность повышает читаемость кода и позволяет улучшать язык обратно-совместимым способом.

Если чуть подробнее, этот стиль наименования:

1. позволяет вводить в язык новые магические методы без риска сломать старый код. Программисты на питоне в своем коде названия __name__ не используют (по соглашению, да и сложно так назвать что-то случайно), а значит новый магический метод ничего не сломает. Без подобного соглашения нужно быть телепатом, чтоб писать код, который не сломается в будущих версиях интерпретатора. Ср., например, с toJSON в javascript — когда в браузерах поддержка этого метода появилась, куча кода перестала работать.

2. при чтении кода сразу видно, что метод магический, и вызываться он, скорее всего, будет неявно. Вызовы остальных методов обычно можно грепом найти. Кстати, название магического метода часто подсказывает, как он может вызываться: если метод называется __foo__, то во многих случаях он будет вызван с помощью функции foo(obj). Например, функции getattr, setattr, len, iter, next, reversed, copy, deepcopy, hash вызывают соответствующие __методы__.

[@Yoschi]

Бывают и менее очевидные вызовы магических методов. Например, сложение вызывается не только для оператора +, но и для встроенной функции sum.

class N():
    def __init__(self, n):
        self.n = n

    def __add__(self, other):
        return N(self.n + other.n)

    def __repr__(self):
        return '<N: %s>' % self.n

print sum([N(1), N(2), N(3)], N(0))

Выводит <N: 6>

[@Yoschi]

Или вот ещё __nonzero__. Вызывается не только когда явно укажешь bool(object), но и просто if obj:
В таком случае bool() применяется к объекту «автоматически».

[@begezavr]

Добавил в табличку ваш пример с if. Но, на самом деле, в обоих ваших примерах было бы странно ожидать от Питона какого-нибудь другого поведения, мне кажется :)

[@Yoschi]

Согласен, это логично. Ещё пара примеров (сами в голову приходят, уж извините :о))
all(iterable) и any(iterable) тоже вызывают bool неявным образом.
С одной стороны, об этом тоже можно догадаться внимательно посмотрев в документацию, а с другой, лучше помнить заранее, чтобы не писать своих хитроумных алгоритмов для проверки истинности «всех», или «хотя бы одного» объекта из списка, когда достаточно определить один простой магический метод и пользоваться встроенными возможностями.

[@stalker320]

Не подскажите как правильно написать _iadd__(self, other)? Я просто слегка не понял этого

[@vvpoloskin]

Ну все, можно смело положить в избранное. Материал обязательно пригодится, когда надо срочно что-то заставить работать по-другомупереопределить

[@MikeLP]

Огромнейшее спасибо. Однозначно в избранное. Я бы даже сделал в виде pdf.

[@wronglink]

Можно добавить еще про новый (с 3 версии питона) магический метод получения следующего значения у итераторов, .__next__(), который принят на вооружение взамен старому .next(). При этом, правильный метод в зависимости от версии питона, отлично вызывается встроенной функцией next().
см. PEP 3114

[@begezavr]

Спасибо, добавил.

[@Yoschi]

__hash__ используется не только для поиска по словарю, но и для проверки вхождения в множество (set()). Хотя, некоторые представляют себе множество словарём без значений… Технически это может и имеет смысл, но как-то совсем не интуитивно.

[@leventov]

__hash__ это просто дуаль встроенной функции hash, а уж кто и как ее использует — дело второе.

[@davinchi]

Нет. Значение, возвращаемое __hash__ для экземпляра класса, является значением, используемым для получения хэша объекта.

class A(object):
    def __hash__(self):
        return 10

a = A()

Вызов hash(a) вызывает __hash__ у объекта a.

>>> class A(object):
...     def __hash__(self):
...             print "i'm called, you are wrong"
...             return 10
... 
>>> a = A()
>>> v = {a: 10}
i'm called, you are wrong

[@leventov]

5 раз перечитал ваш комментарий, не понял, почему «нет». Если бы стандартные словари и множества были реализованы на самом Питоне, а не внутри интерпретатора, там бы использовалась ф-я hash. Любой может сделать свой контейнер и использовать там ф-ю hash, но это не повод писать "__hash__ используется не только для поиска по словарю и для проверки вхождения в множество, но и вот в этом моем контейнере".

[@davinchi]

1) Контейнер не мой, это просто словарь.
2) Так она и используется — но функция hash всего-лишь вызывает __hash__ у объекта. Это не дуаль потому, что hash — это syntactic sugar, а __hash__ *на самом деле* вычисляет значения хэша.

[@homm]

> __hash__ *на самом деле* вычисляет значения хэша
__hash__ вычисляет значение, из которого вычисляется хэш.

[@davinchi]

__hash__ вычисляет *целое* из которого вычисляется хэш. docs.python.org/2/reference/datamodel.html#object.__hash__. По факту можно использовать и это целое, но реализация CPython хочет хэш в виде числа 32 или 64 битного.

[@Yoschi]

set — это встроенная функция и узнать, что она тоже использует hash можно либо добравшись до исходников на C, либо потеряв некоторое время, пытаясь понять, почему даже при определение __eq__ равные объекты внутри множества не считаются равными. Поэтому я посчитал полезным добавить это замечание.

[@anjensan]

Не совсем.

>>> class X(object):
...     def __hash__(self):
...         return 111111111111111111111111111111111111111111111
...         
>>> x = X()
>>> hash(x)
891475464178347604

[@davinchi]

Слишком длинное число, хэш должен помещаться в целое. Он берёт hash от hash'а.

[@svetlov]

Про __del__ неправильно написано. Метод будет вызван если интертретатор завершает работу.
Другое дело что он не вызовется сборщиком мусора (объекты с __del__ сборщик мусора до версии 3.4 не умеет обрабатывать вообще).
__del__ работает только если произошел decref, а не garbage collection.

[@begezavr]

Хм, в документации написано:

«It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.»

Неужели я неправильно перевёл такое, вроде бы несложное предложение?

[@svetlov]

Документация не совсем точна. Следующий параграф Note более внятно описывает что именно происходит

[@begezavr]

Но и там я так и не нашёл утверждения, что вызов __del__ гарантирован :(

Сейчас потестил и всё говорит за то, что вы правы и __del__ на самом деле всегда вызывается по завершению интерпретатора. Добавлю замечание.

[@int19h]

Скорее всего, это относится к общим гарантиям языка, которые не зависят от реализации. Например, это будет справедливо в Jython, IronPython, или другой реализации, не использующей подсчет ссылок, и основанной на стороннем GC, не гарантирующим финализацию объектов при выходе процесса. Как написано в самом начале этой же страницы документации:

«Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable.»

[@Nepherhotep]

Однако, следует пояснить, что это справедливо только для объектов с циклическими зависимостями.
Объекты, у которых есть метод __del__, но без циклических ссылок, удаляются сразу после удаления последней ссылки на него. Метод __del__ у них вызывается сразу.

[@homm]

> На самом деле, экземпляр объекта создаёт метод __new__ и затем передаёт аргументы в инициализатор.
Немного не так. __new__ не передает аргументы в __init__. __init__ вызывается интерпретатором, если __new__ вернул объект того класса. Причем, если вы вернули объект, уже созданный до этого и сохраненный где-то (например, это singleton), то __init__ все равно будет вызван.

[@begezavr]

Спасибо за комментарий, действительно не совсем правильно получилось. Изменил предложение на:

На самом деле, экземпляр объекта создаёт метод __new__, а затем аргументы передаются в инициализатор.

[@davinchi]

Я не уверен, что можно называть __new__ методом, поскольку объекта в этот момент ещё не существует. Это скорее classmethod.

[@SKolotienko]

У меня возникло ощущение, что писать ОО-код на питоне будет порядком мозговзрывательнее, чем, например, на том же С++ (с нормальной IDE с подсказками)

[@Amper]

Вы не правы, модель в питоне очень проста, не обязательно использовать все перечисленные изыски, большинство из них для особых ценителей-извращенцев.

[@Alesh]

Как человек достаточно хорошо знающий и С++ и Python, могу сказать на Python гораздо менее мозговзрывательнее, чем на Це++. Просто с непривычки да, а как втянешься, переписать все на питон останавливает только то, что это все таки транслятор со всеми вытекающими.

[@Anarchist]

Питон в самом деле превосходит Цэ++ по читабельности, но Вы правы в одном — отсутствие типизации в самом деле создает некоторые трудности с подсказками в IDE

[@Amper]

Для полной картины не хватает еще и вещей вроде __dict__, __doc__, __ slots__ и т.д. (хоть это и не методы, но статья бы стала почти идеальной)).
Ну, и еще не хватает __prepare__.

[@davinchi]

Тогда уж можно начать описывать вообще все magic method's, в том числе NumPy'вые.

[@Alesh]

Статья тупо перевод мануала, было бы клёво если бы показали больше примеров зачем это все нужно. Тот же синглетон на __new__.

[@mwizard]

Если в первом примере под тильдой в filepath='~' понимается домашняя директория текущего пользователя, то это так не работает — будет попытка открыть файл в директории ./~/, т.к. Python не разворачивает шелл-подстановки (и спасибо ему). Чтобы работало, код нужно написать следующим образом:

    def __init__(self, filepath = '~', filename = 'sample.txt'):
        # открыть файл filename в filepath в режиме чтения и записи
        self.file = open(os.path.expanduser(os.path.join(filepath, filename)), 'r+')

Более того, опасно использовать __del__ так, как это было продемонстрировано, так как __del__ вызывается даже для тех экземпляров класса, для которых не было завершено конструирование. Таким образом, если создать FileObject с неправильным именем файла, open() выбросит IOError, и self.file не будет присвоен — но к нему обратится __del__ и получит вдобавок еще и AttributeError, и последующая деинициализация выполнена не будет, лишая __del__ того смысла, который в него вкладывал автор. Будьте осторожнее.

[@mwizard]

В Python 3 больше нет метода __cmp__() и функции cmp(), и рекомендуется использовать __lt__/__gt__/__le__/__ge__/__eq__/__ne__ исключительно. Если нет необходимости определять все операторы сравнения, можно определить один оператор сравнения (например, __eq__) и один оператор упорядочения (например, __lt__), и применить к объявлению класса декоратор @functools.total_ordering — он достроит остальные функции на основании имеющихся.

[@begezavr]

В статье есть всё из того, что вы написали.

[@renskiy]

Про __metaclass__ нет упоминания, и это, как мне кажется, большое упущение. На хабре даже есть подробная статья, посвященная этой теме: Метаклассы в Python.

[@begezavr]

Про __dict__, __name__, __doc__ тоже ничего нет, потому что статья про магические методы, а не про всю объектную модель Питона вообще. А метаклассы это вообще отдельная тема.

[@renskiy]

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

Отдельные темы оформляются отдельными ссылками (на соответствующие статьи).

Не кажется ли вам, что неправильно давать материал в отрыве от контекста? То есть без возможности продолжить изыскания на смежные темы. Уважение к читателю — важная составляющая работы любого автора.

[@begezavr]

Я всего лишь перевёл статью. А продолжить изыскания всегда можно в гугле.

[@idle]

Зря так часто специализированные методы называют «магическими». В них нет никакой магии, в них — специализация.

Любителям магии и пошалить: смотрите занятие от Бизли с Pycon2013 US, где разбирается работа метаклассов и дескрипторов.

[@Yoschi]

Магическими их называют потому-что обычно на прямую их не вызывают и определить их назначение в коде можно только обладая сакральными знаниями :о)

[@idle]

Ага, тогда, пожалуй, любой метод, который, скажем, обычно вызывают не напрямую, сказочным образом становится магическим ;)
Неее, тут явно не обошлось без неутоленного в детстве желания волшебства.

[@Yoschi]

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

[@mwizard]

Есть быстрый и безопасный cerealizer.

[@trak]

Спасибо за статью, плюсовать ее поздно, а благодарность выразить хочется, большое спасибо!