4 совета как ЛУЧШЕ применять TypedDict в Python
![ZProger [ IT ]](http://yt3.ggpht.com/ytc/AIdro_nEayoD4jBvKkG7VFnuTm_Rnd64g6RPSHL9K53LulYXDQ=s48-c-k-c0x00ffffff-no-rj)
Вставка
- Опубліковано 12 чер 2024
- ⭐ Курс ООП и Приват канал: www.zproger-school.com/?...
⭐ Размещайте свои проекты на доступных серверах Vscale: slc.tl/0cf06
⭐ Телеграм канал: t.me/+4BVQJYsr8-o2OWNh
В данном видео рассмотрим главные минусы Python dict. Использование фишек из видео позволяет отслеживать типизацию Python словарей и обнаруживать ошибки в проектах еще на этапе написания кода.
Такой подход улучшает безопасность приложений и сокращает время его разработки.
📁 Github: github.com/Zproger
📁 Все плейлисты с уроками: bit.ly/39GaY89
📁 Связаться со мной: zproger777@gmail.com
📁 Поддержать канал: github.com/Zproger/donate
📁 Исходный код: скоро
Тайм-коды:
0:00 - Какие есть недостатки у python dict?
2:23 - Недостатки с dict типизацией python
2:50 - 1. Как TypedDict решает все это?
3:43 - Интеграция Selectel
4:29 - 2. Как TypedDict делает код более явным?
5:29 - 3. Преимущества TypedDict над Python dict
7:58 - 4. Динамический код с TypedDict в Python
Если есть возможность затащить в проект пайдантик зависимостью, то это, как по мне, будет куда удобнее и полезнее. Чисто для аннотации словарей, скорее всего, можно использовать TypedDict, но я практически не встречал его в каких-то популярных опенсорсных проектах, если нужна ванила, то отдал бы предпочтение датаклассам.
Зачем добавлять в свой код строгую типизацию и потом костылями её обходить, если можно просто использовать для таких целей датаклассы, которые легче и проще? А в случаях, когда тебе действительно нужно валидировать json\xml\protobuf, то есть pydantic или marshmallow (для xml - xmltdict + что-то из вышесказанного), которые имеют для валидации больше возможностей
Потому что датаклассы и TypedDict это совершенно разные вещи и нужны для разных ситуаций. Иногда нужен dataclass, иногда Enum, а иногда TypedDict, и не получится всегда применять одно и тоже.
Вижу комментарий был изменен. Ну в целом если речь о pydantic, тогда да, но все же иногда проще сделать типизированный словарь. Все зависит от ситуации.
например?@@zproger
Наверное не стоит в принципе обращаться к словарю по ключу без .get()
если строгую типизацию в коде приходиться обходить костылями, то речь идет уже не о коде
Нужно сравнение TypedDict, NamedTuple, и Dataclass
Благодарю за идею!
И attrs
какая музыка использовалась на заднем фоне в плейлисте про мультипроцессинг?
И чем лучше датакласов тогда? Какое-то среднее нечто между датакласом и диктом
Подскажите пожалуйста название темы, которая стоит у вас в PyCharm, эта комбинация цветов бесподобна 😍
У меня один вопрос, если я принимаю JSON с бэка то что мне нужно использовать?
Привет, что за дистрибутив линукс у тебя стоит? как поставить такой же? чтобы внешний вид был такой, сверху оперативка, цпу градусы и %?
Привет, будет видео на канале, еще не доделал оболочку
@@zproger жду!!
А такая аннотация подойдет?
-> dict[Union[str, int], Any]
Используешь visual studio code? Или его опенсорс аналог?
это Pycharm
он же и так опенсурс?
Я только что искал информацию про словари, и пришло в тг уведомление о новом видео. И какая же тема? 😄 Совпадение?) Спасибо)
:)))
А что за IDE ты юзал в видеве?
как ты сделал такую красивую верхнюю шторку? где показывается кол-во рабочих столов, температура, цп и тд? и какой у тебя дистрибутив
Это polybar, дистрибутив arch linux
Интересно)
Благодарю!
хорошо преподнёс, спасибо
Благодарю
Привет . берётесь ли вы за написание индикаторов и соединения с криптобиржами на Питоне?
На данный момент нет
Бро это Arch ? какой wm используешь ?
Arch
спасибо, не знал 😢
Рад что был полезен
Что у тебя за терминал? И что за шрифт в полибаре?
Alacritty + JetBrains
Может странный вопрос - зачем пользоваться ТАйпед Дикт если есть датаклассы?
Иногда нужно использовать именно словари, но обычный dict плохо справляется в некоторых ситуациях (как показано в видео), и вот именно в таких случаях можно юзать TypedDict.
Или например модели pydentic?
@@zproger Имели ли вы когда нибудь такие кейсы, в каких случаях мможет такое случаться ?
Да, когда нужно готовить четкие шаблоны для ответов в виде словарей. В таких случаях очень круто заранее описать возможные сценарии ответов и дать им типизацию. Когда это будет заполняться в других частях софта, то разработчик не пропустит необходимые ключи и укажет именно те типы данных, которые там необходимы.
@@zproger то есть, TypedDict нужен как прослойка между, условно, легаси, работающем на словарях, и новым кодом? Просто новый код как раз проще написать сразу на дата классах или pydantic/attrs.
А что если сразу использовать класс? 😌
ОРМка для словарей, гениально! xD
а это работает быстрее обычных словарей? если да и скорость выполнения существенная то смысл есть иначе жопоболь
Тут фишка немного в другом, по скорости это не будет работать быстрее, но если вы допустите ошибку с обычными словарями и с TypedDict, то на устранение потребуется разное время. И уже тут вы выиграете в скорости за счет удобства работы с типизированным словарем.
@@zproger это смотря какая задача. В своих проектах я обычно упираюсь в скорость выполнения.
Сделай видео о том, как ты настроил vs code и linux, выглядит очень классно))
Это дефолтный PyCharm. Про линукс планируется видео, спасибо.
@@zprogerу меня выглядит по другому, я так понял это другой стиль ?
@@d.I.m.a.s256s это новый UI, появился с 2023, кажется, версии. В настройках ищется по New UI.
точно pydantic, пару недель назад смотрел как подобным способом проверяли валидность приходящих данных для FastAPI
Питон всё больше скатывается в переусложнённость.
Лично мне он нравится как простой скриптовый язык вроде LUA.
для таких, как ты, он остался простым -- пиши, как раньше
По мне их очень редко используют ибо не нужно.
Даже именованные кортежи чаще используют
Хочу перейти на rust😅. Но блин уже столько пройдено. Заного начинать мой раздутый пэт проект - не охота🥲
Бывает)
зачем это все если есть pydantic
затем, что не всегда он доступен
Этот "эм" это фишка чтоли?🥲🥲
Да :)
pydantic привет
:))
Какой-то бред. Я никогда не видел смысла в пакете typing. Если нужен словарь - ты будешь использовать словарь. Если нужен класс - будешь использовать класс. Я спокойно создавал классы, а потом просто обращался к их свойствам. И все вот эти надстройки и поверхностые оболочки над базовыми структурами данных зачастую не нужны. Этих двох структур достаточно с головой. А если кто-то допускает ошибки - он просто новичок, который меньше месяца учит язык и почти ничего не знает о технологиях проектирования, архитектуры ПО, сборки и т.д. Разработчик с опытом 6-9 месяцев и больше не будет допукать никогда таких ошибок, которые были описаны в начале ролика (за исключением случаев, если разработчик не спал два дня, работает больше 20 часов подряд и очень хочет спать). В крайнем случае, кто мне мешает перейти к функции и посмотреть, какой словарь ей возвращается??? Это будет проблемой только для тех, кто не умеет анализировать чужой код или для тех, кому лень потратить 1-8 секунд на просмотр структуры словаря...
Типизация очень важна, и элементарное добавление таких аннотаций избавляет от огромного количества ошибок еще на этапе статики, не зря все крупные проекты с ног до головы пропитаны typing, mypy, pyright и т.д.
Фишка типизации именно в том, что статические анализаторы будут ловить возможные ошибки еще только на этапе их формирования, и это исключает шанс того, что эта ошибка обнаружится именно на рантайме.
@@zproger , я знаю, что типизация важна. Я ввиду имел, что для типизации достаточно обычного dict (если говорить о словаре). Как ты наводил пример
def some_function() -> dict:
return {"res": 5}
Если ты сомневаешься в типе - перейди в функцию и посмотри какого типа значение ключа. Ну или если получаешь ошибку - конвертируй тип
print("Result is " + str(some_function["res"]))
а ещё лучше в этом примере написать
print(f"Result is {some_function["res"]}")
в этом случае все типы сами конвертируются, как нужно Питону.
Я понимаю, что это самые простые примеры, но такой принцип работает в проекте любой сложности. Если вся проблема в незнании типа, не проще ли его просто посмотреть в функции или где ещё?
Я знаю, что словарь может изменятся в процессе работы и в одно время там может храниться значение одного типа, а потом - другого. В этом случае проще переводить все занчения в тип строк. По этому в словаре для всех ключей всегда будут храниться строки. А потом можно строку конвертировать в нужный тип.
Я просто хотел донести смысл, что нет нужды использовать какие-то обёртки над стандартными Питоновскими типами. Может для какого-то единствееного уникального проекта и будет смысл использовать "специализированную" бибилотеку, которая реализует такие типы, которых нет в Питоне. Но если язык даёт возможность типизировать переменные - лучше использовать возможности самого языка, а не какого-то модуля.
Я сторонник такого программирования, где минимизируются сторонние библиотеки. Я по максимуму выжымаю ресурсы самого языка и если уже чего-то нет в языке - только потом обращаюсь к библиотекам.
@@nakamasama какую чушь ты написал! typing -- это самый что ни на есть стандартный модуль, а не "специализированный"
Понимаю, что комменту уже месяц, но все же.
В идеальном мире мы все пишем сами, с нуля, да на чистой архитектуре. А в ральности случается конфиг на UserDict с парой сотней опций)))
Еще один случай. Есть софтинка с очень мощным python api. Только вот сделано оно через парочку интерфейсов для совместимости с питоновскими типами. В итоге получаем автосгенерированную документацию на пару тысяч классов и обсолютное отсутствие какого либо code completion. Очень весело ловить None'ы-нежданчики в рантайме. Ну или пытаться угадывать какой из наследников "struct_base" хочет та или иная функция на вход 👍
Так же над одним и тем же кодом может работать несколько людей. Типы это, считай, половина документации к коду.
Модуль typing заставляет тебя думать о своих структурах данных. А это 1) полезно для тебя 2) полезно для тех кто твой код читает 3) открывает путь для pylance, mypy, pytype 4) упрощат написание/генерацию доков. Это слишком круто, чтобы игнорить
А для чего так перегружать код, когда можно просто посмотреть что от тебя требует словарь. Ведь посмотреть тебе нужно только один раз. А пайтону потом всю жизнь обрабатывать эти лишние строчки кода на сервере. Нужно же наоборот учиться писать код как можно проще для Интерпретатора так как она будучи загружена на сервер, будет выполнять код, а не для того чтобы там сэкономим 5 секунд своего времени.
Мы живём в эпоху, когда машиночасы стоят на порядки дешевле, чем человекочасы. Так что если мы не говорим о высоких нагрузках, то сэкономить 5 секунд себе - это лучше, чем сэкономить 5 наносекунд машине. А высокие нагрузки - это уже совсем другая история.
Но вообще все эти аннотации с типами отбрасываются после компиляции в байткод, так что на запущенном приложении они не несут дополнительной нагрузки.
не совсем понял почему стринга стала интом в последнем TypeVar ? group[1]
потому что он специально так написал