Comments 20
нашествие статической типизации в скриптовые языки, которые до этого дцать лет нормально жили без нее - это печально
Единственная ситуация при которой скриптовый язык живёт нормально - это пока программа умещается на экран. Дальше начинается специальная олимпиада: "я могу удержать весь код в голове".
расползается этот рак статической тпизации
Лол.
Так типизация начинает решать, когда MVP написанный на коленке со всеми преимуществами динамической типизациии начинают поддерживать больше 3-х человек) Зачем переписывать проект на плюсы, если можно заразить его раком типизации и упростить поддержку в разы.
Не очень понимаю при чем тут статическая типизация! Pydantic это библиотека, которая использует синтаксис аннотации типов для описания сигнализаторов/валидаторов, которые в отличие от сигнализаторов DRF, можно использовать как объекты. В DRF же вам придется либо использовать промежуточные классы либо как раньше писать всю логику на dict-ах. ModelSerializer подходит только для банальных случаев.
Созданные с pydanctic классы поддерживаются type cheker-ами. Но это бонус, никто не заставляет вас их использовать, пока сами не захотите.
Сигнализаторов - это что? Не встречал. Может речь идет о сериализаторах?
О реальной статической типизации речь, разумеется, не идет. Все, что у нас есть - это аннотация типов, которая была возможна с самого начала через docstrings и чекеры работали. Я не очень понимаю, почему этот вариант не устраивал, когда смысл тот же.
Вероятно, что на мою не совсем корректную терминологию повлиял Guido со своими набросками 2000 года об опциональной статической типизации. Или тут. Я прочитал это, конечно, намного позже, но в голове закрепился именно этот термин.
Спасибо, за замечание, соласен, что аннотация типов более точное обозначение.
О реальной статической типизации речь, разумеется, не идет. Все, что у нас есть - это аннотация типов, которая была возможна с самого начала через docstrings и чекеры работали. Я не очень понимаю, почему этот вариант не устраивал, когда смысл тот же.
Не видел, чтобы тайп чекеры могли брать типы из докстрингов. Это какой из анализаторов такое умеет?
Возможно, вы имели ввиду тайп аннотации через комментарии, как это делалось в Python 2 за неимением лучших альтернатив?
А вот здесь (PEP 3107) есть ответ по поводу "не понимаю зачем тайп аннотациям отдельный синтаксис". Это просто способ стандартизировать тот зоопарк решений, который был придуман сообществом для решения проблемы приделывания типов к функциям. There should be one-- and preferably only one --obvious way to do it.
Пайчарм молодцы, они много чего такого умеют. К сожалению, что сделано в пайчарме, остаётся в пайчарме, и не может быть переиспользовано, например, в CI или пользователями других редакторов, поэтому я не склонен считать его за полноценный тайп чекер (не умаляю его заслуг, он хорош, но не универсален). Универсальные IDE-agnostic тайп чекеры, типа mypy, pyre или pyright, никогда не умели работать с докстрингами. Да им и не надо, ведь есть отдельный, стандартизованный синтаксис для аннотаций. Теперь эта фича пайчарма выглядит скорее как рудимент.
Увы нормальное создание на лету PYDANTIC-классов на базе Django-моделей невозможно. Это минус. Решение возможно, но есть нюанс.
Хотелось бы уточнить, в чем проблема использовать from_orm()?
Да, норм метод, согласен. Можно даже поправить в репозитории. Только для Django не очень подходит: ModelField Pydantic не отражает всех параметров полей моделей Django, особенно, если в модели есть свои собственные поля. Попробуй сам, например, Decimal field с неопределенными точка или запятая как разделитель. Ну или ImageField.
Я использовал Pydantic с Django наверно уже в 5-8 микросервисах и честно говоря ни разу не натолкнулся пока (!, это важно, потому что может мне просто повезло), в такие ограничения. Какие именно параметры полей должна отразить модель Pydantic? Мне кажется эту библиотеку иногда заставляют делать то, к чему она не совсем предназначена.
Не совсем понял про свои собственные поля в модели? Можете, пжлст, привести пример?
Для разных типов разделителей можно написать свою валидацию, не вижу в этом проблемы. ImageField - надо проверить, у меня пока не было кейса в использовании. Возможно тут вопрос опять в том, для чего Pydantic использовать? Для валидации multipart form он не подойдет, конечно. С другой стороны он поддерживает кастомные типы.
У нас в проекте переписаны to_python DECIMAL-полей. В Django метод "to_python" - это предобработчик одного значения из переданного комплекта данных до валидации. В твоем комментарии уже есть вероятное решение как это реализовать в Pydantic: можно создать кастомный тип для обработки значений подобных полей.
Так же, по умолчанию, для Django-модели со строковым полем ... min=3... max=15 автоматически у меня не брала валидатор min_length. Вероятно, что-то не то делал.
Для всех наследников Django FileField я придумал как использовать Pydantic.FilePath ну плюс подглядел в fastapi.issue тему про UploadFile. Но опять же нужна доработка.
После многих лет с Django от подобной библиотеки хотелось бы, как-то больше "из коробки" что ли. А то создать навороченный валидатор зачитывая словарь __annotations__, а до появления annotations из правильно написанного__doc__ я и сам могу.
Категорически не хватает ссылки на упомянутое выступление, где автор скрещивает Django с Pydantic. Не понятно же из-за чего весь сыр-бор. Гугл тоже не признаётся, хотя возможно я плохо спрашивал.
django-ninja недавно начал поддерживать создание классов на базе моделей Django, но там, похоже, внутри djantc.
Не суйте свой Pydantic в мое Django