Абстрактные классы и интерфейсы в Питоне

[dicos]

Где-то видел такой подход:

class interface:
    def query(self):
        pass
    def select(self):
        pass

[Infernal]

class Derived(interface):
    pass

derived_object = Derived()

Будет работать, несмотря на то что потомок не реализовал методы query и select.
Если бы в этом случае использовался, например, модуль ABC, то при попытке создать экземпляр класса Derived выбросилось бы исключение TypeError. Пример пользователя neithere тоже выбросит исключение, но только при попытке вызвать какой-либо из нереализованных методов

[VlK]

Не пробовал, но, думаю, аналогичный abc функционал можно сделать инвариантами в zope.interfaces

[neithere]

Или так:

class Movable:    
    @property
    def speed(self):
        raise NotImplementedError
    def move(self):
        raise NotImplementedError

Преимущество — используются только стандартные средства.
Недостаток — ошибка вываливается при обращении к атрибуту, а не на этапе создания экземпляра.

[VlK]

Ну вы сами все сказали. Развитие этой идеи и приводит к интерфейсам либо велосипедо-интерфейсам.

[akira]

А можно попросить подсветить?

[VlK]

Можно. Ночью лень уже стало заморачиваться :)

[muslimov]

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

[VlK]

В общем-то да, такие штуки редко нужны. Однако, если система действительно большая и сложная, то без интерфейсов становится тяжеловато. Компонентную архитектуру ввели в Zope именно поэтому — упростить и разделить на явные стандартизированные составляющие.

Что бы там не говорили про Яву в малых и десктопных приложениях, а рынок средних-крупных систем для бизнеса и финансов она держит плотно, возможно, именно благодаря таким фишкам.