Ещё про изменения в Python 3.12. Недавно приняли PEP 698 – Override Decorator for Static Typing.

Идея простая. Часто в коде переопределяются методы родительских классов, но происходит это сейчас неявно. То есть когда всё хорошо, то тайп-чекер видит, что у родителя есть метод Parent.foo(), у ребёнка есть метод Child.foo(), они называются одинаково, а значит один переопределяет другого. Но вот когда что-то начинает меняться (например, Parent.foo() переименовывается или удаляется, а Child.foo() почему-то остаётся нетронутым), то для тайп-чекера уже не очевидно, что эти два метода как-то были между собой связаны. К сожалению, тайп-чекер видит только нынешнее состояние кодовой базы и не знает с какой стороны мы в это состояние пришли. Короче, есть риск выполнить рефакторинг наполовину, потеряв связи между родителями и детьми, из-за чего много чего может пойти не так, а тайп-чекер просто не увидит проблемы.

В PEP 698 добавляется декоратор @typing.override, который показывает, что отмеченный метод класса является переопределением одноимённого метода родителя. Если у родителя нет такого метода, то тайп-чекер заметит ошибку — хотели что-то переопределить, но только вот непонятно что. Придётся идти и чинить, приводить код в согласованное состояние.

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

Примечательно, что авторы инициативы все из Фейсбука, и пробную имплементацию они тоже занесли в свой фейсбучный тайп-чекер pyre. Похоже, у них там наболело.

Питонические атаки

Ещё про изменения в Python 3.12. Недавно приняли PEP 698 – Override Decorator for Static Typing.

Идея простая. Часто в коде переопределяются методы родительских классов, но происходит это сейчас неявно. То есть когда всё хорошо, то тайп-чекер видит, что у родителя есть метод Parent.foo(), у ребёнка есть метод Child.foo(), они называются одинаково, а значит один переопределяет другого. Но вот когда что-то начинает меняться (например, Parent.foo() переименовывается или удаляется, а Child.foo() почему-то остаётся нетронутым), то для тайп-чекера уже не очевидно, что эти два метода как-то были между собой связаны. К сожалению, тайп-чекер видит только нынешнее состояние кодовой базы и не знает с какой стороны мы в это состояние пришли. Короче, есть риск выполнить рефакторинг наполовину, потеряв связи между родителями и детьми, из-за чего много чего может пойти не так, а тайп-чекер просто не увидит проблемы.

В PEP 698 добавляется декоратор @typing.override, который показывает, что отмеченный метод класса является переопределением одноимённого метода родителя. Если у родителя нет такого метода, то тайп-чекер заметит ошибку — хотели что-то переопределить, но только вот непонятно что. Придётся идти и чинить, приводить код в согласованное состояние.

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

Примечательно, что авторы инициативы все из Фейсбука, и пробную имплементацию они тоже занесли в свой фейсбучный тайп-чекер pyre. Похоже, у них там наболело.

Python Enhancement Proposals (PEPs)

PEP 698 – Override Decorator for Static Typing | peps.python.org

This PEP proposes adding an @override decorator to the Python type system. This will allow type checkers to prevent a class of bugs that occur when a base class changes methods that are inherited by derived classes.

👍10🔥4

hottg.com/pythonic_attacks/543

1.48K viewsFeb 7, 2023 at 17:11