Комментарии 16
Вообще почти все решения продвигались создателем языка именно ради простоты и наглядности. За что он и был с успехом воспринят как в академ среде, так и в смежных отраслях, двигающих софтовую часть IT.
А теперь выясняется, что все нужно бросить и начать переживать: «как там бедные статические анализаторы? Не тратят ли лишние такты CPU?»
После прочтения статьи остро вспомнились последние стандарты плюсов — из лаконичного языка он превратился в что-то трудно удержимое в голове без справочника под рукой.
typing — это просто пример того, как эти метаданные могут быть использованы.
Далеко не все используют аннотации, многие про них и не слышали. Для таких людей Python в плане синтаксиса, каким был таким и остался.
Аннотации же вещь чисто опциональная, хочешь используешь, хочешь нет. К тому же, проблема дополнительных вычислительных затрат относиться лишь к моменту запуска программы, в период выполнения, аннотации никак вычислительные ресурсы не используют.
Питон остался всё таким же компактным.
Однако сильно упростился для написания кода, когда тебе не нужно проверять что именно возвращает та или иная функция, или делать всякие шаманские телодвижения чтобы ИДЕ показала подсказки типизации.
В жизни, конечно, все будет зависеть от технической грамотности и дальновидности архитектора проекта, но в идеальном вакууме как-то так.
Да, всё так. Потому что, Гвидо делал язык, чтоб быстро скрипты до 100-и строчек на коленке делать, а потом на нём зачем-то стали ваять всякие фреймворки и приложения с десятками участников и тысячами строк кода. В таких приложениях, конечно нужна типизация. И, конечно, важна производительность. Пока старый синтаксис не запретили, можно ещё пользоваться. Потом придётся переходить на Lua.
Второй уровень — это способность читать чужой код на этом же языке без эмоций: «А это что за странный синтаксис?! Никогда такого не видел!». Если стандартом языка что-то утверждено, то знать и понимать нужно все из этого стандарта, а не только интересную сейчас его половину.
P.S. Сорри, комментарий был к ответу выше
Поправьте, если я не прав, но PEP 563 работает начиная с Python3.7, который вышел больше 4 лет назад (надо было только написать from __future__ import annotations). У меня есть проект, решающий похожие на pydantic задачи и в нем не было проблем связанных с этим PEP. Есть подозрение, что проблемы Pyndatic связаны не с питоном, а c принятыми ими неверными решениями.
Аннотации типов можно использовать для двух вещей, связанных с классами, хранящими данные. Во-первых, это валидация кода - что переданные данные соответствуют задекларированным типам полей (проверка типов). Во-вторых, это преобразование примитивных структур данных с датакласс (парсинг). Первая задача решается статическими анализаторами, такими как mypy или pyright. Вторая задача в общем случае должна решаться отдельным слоем кода (вспоминаем single responsibility, разделение DTO и view-слоя и т.п.).
Разработчики pydantic почему-то решили, что задачу парсинга данных должен решать тот же класс, что и хранит их. Из этого следуют следуют такие ограничения как: невозможность использовать для хранения данных стандартные датаклассы, невозможность иметь нескольких вариантов парсинга в одну структуру и, самое главное в рамках текущей статьи, необходимость иметь полную информацию об аннотациях на момент конструирования класса.
from __future__ importКод, написанный в Jupyter (pandas и т.д.) ~1.5 года назад уже дважды правился после минорных
pip install --upgradeТут двоякая ситуация, с одной стороны сам разработчик PEP 563 признал, что typing.get_type_hints плохо работает для не глобальных пространств имен (основаная претензия Pydantic).
С другой стороны, многие библиотеки уже адаптированы под PEP 563, и говорить им, что он отменяется, переходите на PEP 649, тоже не рабочий вариант.
Думаю проще Pydantic подстроиться под Python, а не Python подстраиваться под библиотеку.
def simplify_python():
remove_types()
def complicate_python():
add_types()
while 1:
simplify_python()
while 1:
complicate_python()
if python_looks_like_cpp(): break
Будущее аннотаций типов в Python