Типизированный Python для профессиональной разработки [Алексей Голобурдин] (pdf) читать постранично, страница - 3
- Типизированный Python для профессиональной разработки [СИ] 3.35 Мб, 68с. скачать: (pdf) - (pdf+fbd) читать: (полностью) - (постранично) - Алексей Голобурдин
Книга в формате pdf! Изображения и текст могут не отображаться!
[Настройки текста] [Cбросить фильтры]
- 1
- 2
- 3
- 4
- 5
- . . .
- последняя (18) »
редакторе кода в вашей IDE, либо хотя бы на этапе
проверки программы перед её сборкой и публикацией на сервер.
На википедии есть прекрасная страница про системы типов, Type system:
Wikipedia
The main purpose of a type system is to reduce possibilities for bugs in computer
programs by defining interfaces between different parts of a computer program, and
then checking that the parts have been connected in a consistent way.
То есть главной целью системы типов является уменьшение вероятности ошибок в
компьютерных программах путём определения интерфейсов между разными
частями программы и последующей проверки, что эти части соединены друг с
другом правильным образом через эти интерфейсы. Под интерфейсами тут
подразумеваются собственно типы данных, например, какие-то конкретные классы,
которые описывают конкретные поля и методы.
Допустим, у нас есть вот такая функция:
def validate_user(user):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Под user тут подразумевается объект юзера, например, ORM объект, то есть запись
из базы данных, преобразованная в специальный Python объект. Человек,
написавший код, это знает. В момент написания кода знает. Через месяц он об этом
совершенно точно забудет, а человек, не писавший этот код, об этом знать вовсе не
может. По сигнатуре функции def validate_user(user) нельзя понять, какой тип
данных ожидается в user, но при этом очень легко сделать предположение об этом
типе — и ошибиться.
Спустя пол года дописывается какой-то новый код и функция validate_user в нём
внезапно начинает вызываться с аргументом user, который равен не ORM объекту, а
числу — просто потому что совсем неочевидно, что в user на самом деле
подразумевается не число:
user_id = 123
validate_user(user_id)
Этот код упадёт только в рантайме. Потому что IDE или статический анализатор кода
не смогут понять, что тут есть какая-то ошибка.
Как сделать так, чтобы мы узнали об ошибке до этапа рантайма? Явным образом
указать тип для атрибута user, например, если это экземпляр датакласса User, то так
(о датаклассах мы поговорим подробнее дальше):
from dataclasses import dataclass
import datetime
@dataclass
class User:
username: str
created_at: datetime.datetime
birthday: datetime.datetime | None
def validate_user(user: User):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Датакласс определяет просто структуру данных с полями username, created_at и
birthday, причём тип поля username — строка, тип created_at — datetime, а birthday
хранит None или значение типа datetime.
И теперь такой код:
user_id = 123
validate_user(user_id)
подкрасится ошибкой уже в IDE на этапе написания кода (например, в PyCharm или
настроенном VS Code или nvim), а также код упадёт с ошибкой в статическом
анализаторе кода, который запустится при сборке проекта перед его публикацией на
сервер.
Получается, что наша программа стала надёжнее, так как пользователи не увидят
многие ошибки, они будут выявлены и исправлены на ранних этапах. Да, при этом
надо писать типы, вводить их, думать, но кому сейчас легко:). Нам платят деньги за
качественный софт, а качественный софт это в первую очередь надёжный софт, то
есть софт, который не падает в рантайме с непонятными пользователю ошибками
вроде AttributeError.
Важно
Цена исправления ошибки в программе тем меньше, чем раньше этап, на
котором эта ошибка выявлена. Главная причина введения системы типов —
уменьшение вероятности возникновения ошибок в рантайме, то есть при
эксплуатации приложения.
Читаемость, понятность и поддерживаемость кода
Вернёмся к нашей функции:
def validate_user(user):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Представим, что ты пока не очень опытный программист, который только пришел в
компанию, и тебе дали задачу добавить ещё одну проверку по юзеру, чтобы
валидацию проходили только пользователи, созданные вчера или раньше. Ты этот
код очевидно не писал, видишь его впервые и как тут всё работает ещё не знаешь.
Тут user — это что? Это словарь key-value? Это ORM объект? Это Pydantic модель? У
этого юзера тут есть поле created_at, дата создания, или нет? Оно нам в нашей
задаче ведь нужно будет.
Как ответить на эти вопросы? Перелопачивать код, который вызывает эту нашу
функцию validate_user. А там тоже непонятно, что в user лежит. Там 100500 функций
выше, и где и когда там появляется user и что в нём лежит — большой-большой
вопрос; плюс мы нашли 2 сценария, в одном наша функция вызывается с dict'ом, то
есть user это словарь, а в другом сценарии функция вызывается с ORM моделью, и
возможно еще какой-то код вызывает еще как-то иначе нашу горе-функцию
validate_user. Вот как с этим жить? Вам может понадобиться конкретно
перелопатить весь проект, чтобы понять, как добавить абсолютно простейшую
проверку.
А если бы здесь был такой код — то все вопросы решились бы мгновенно:
from dataclasses import dataclass
import datetime
@dataclass
class User:
username: int
created_at: datetime.datetime
birthday: datetime.datetime | None
def validate_user(user:
проверки программы перед её сборкой и публикацией на сервер.
На википедии есть прекрасная страница про системы типов, Type system:
Wikipedia
The main purpose of a type system is to reduce possibilities for bugs in computer
programs by defining interfaces between different parts of a computer program, and
then checking that the parts have been connected in a consistent way.
То есть главной целью системы типов является уменьшение вероятности ошибок в
компьютерных программах путём определения интерфейсов между разными
частями программы и последующей проверки, что эти части соединены друг с
другом правильным образом через эти интерфейсы. Под интерфейсами тут
подразумеваются собственно типы данных, например, какие-то конкретные классы,
которые описывают конкретные поля и методы.
Допустим, у нас есть вот такая функция:
def validate_user(user):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Под user тут подразумевается объект юзера, например, ORM объект, то есть запись
из базы данных, преобразованная в специальный Python объект. Человек,
написавший код, это знает. В момент написания кода знает. Через месяц он об этом
совершенно точно забудет, а человек, не писавший этот код, об этом знать вовсе не
может. По сигнатуре функции def validate_user(user) нельзя понять, какой тип
данных ожидается в user, но при этом очень легко сделать предположение об этом
типе — и ошибиться.
Спустя пол года дописывается какой-то новый код и функция validate_user в нём
внезапно начинает вызываться с аргументом user, который равен не ORM объекту, а
числу — просто потому что совсем неочевидно, что в user на самом деле
подразумевается не число:
user_id = 123
validate_user(user_id)
Этот код упадёт только в рантайме. Потому что IDE или статический анализатор кода
не смогут понять, что тут есть какая-то ошибка.
Как сделать так, чтобы мы узнали об ошибке до этапа рантайма? Явным образом
указать тип для атрибута user, например, если это экземпляр датакласса User, то так
(о датаклассах мы поговорим подробнее дальше):
from dataclasses import dataclass
import datetime
@dataclass
class User:
username: str
created_at: datetime.datetime
birthday: datetime.datetime | None
def validate_user(user: User):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Датакласс определяет просто структуру данных с полями username, created_at и
birthday, причём тип поля username — строка, тип created_at — datetime, а birthday
хранит None или значение типа datetime.
И теперь такой код:
user_id = 123
validate_user(user_id)
подкрасится ошибкой уже в IDE на этапе написания кода (например, в PyCharm или
настроенном VS Code или nvim), а также код упадёт с ошибкой в статическом
анализаторе кода, который запустится при сборке проекта перед его публикацией на
сервер.
Получается, что наша программа стала надёжнее, так как пользователи не увидят
многие ошибки, они будут выявлены и исправлены на ранних этапах. Да, при этом
надо писать типы, вводить их, думать, но кому сейчас легко:). Нам платят деньги за
качественный софт, а качественный софт это в первую очередь надёжный софт, то
есть софт, который не падает в рантайме с непонятными пользователю ошибками
вроде AttributeError.
Важно
Цена исправления ошибки в программе тем меньше, чем раньше этап, на
котором эта ошибка выявлена. Главная причина введения системы типов —
уменьшение вероятности возникновения ошибок в рантайме, то есть при
эксплуатации приложения.
Читаемость, понятность и поддерживаемость кода
Вернёмся к нашей функции:
def validate_user(user):
"""Проверяет юзера, райзит исключение, если с ним что-то не так"""
validate_user_on_server(user)
check_username(user)
check_birthday(user)
Представим, что ты пока не очень опытный программист, который только пришел в
компанию, и тебе дали задачу добавить ещё одну проверку по юзеру, чтобы
валидацию проходили только пользователи, созданные вчера или раньше. Ты этот
код очевидно не писал, видишь его впервые и как тут всё работает ещё не знаешь.
Тут user — это что? Это словарь key-value? Это ORM объект? Это Pydantic модель? У
этого юзера тут есть поле created_at, дата создания, или нет? Оно нам в нашей
задаче ведь нужно будет.
Как ответить на эти вопросы? Перелопачивать код, который вызывает эту нашу
функцию validate_user. А там тоже непонятно, что в user лежит. Там 100500 функций
выше, и где и когда там появляется user и что в нём лежит — большой-большой
вопрос; плюс мы нашли 2 сценария, в одном наша функция вызывается с dict'ом, то
есть user это словарь, а в другом сценарии функция вызывается с ORM моделью, и
возможно еще какой-то код вызывает еще как-то иначе нашу горе-функцию
validate_user. Вот как с этим жить? Вам может понадобиться конкретно
перелопатить весь проект, чтобы понять, как добавить абсолютно простейшую
проверку.
А если бы здесь был такой код — то все вопросы решились бы мгновенно:
from dataclasses import dataclass
import datetime
@dataclass
class User:
username: int
created_at: datetime.datetime
birthday: datetime.datetime | None
def validate_user(user:
- 1
- 2
- 3
- 4
- 5
- . . .
- последняя (18) »
Последние комментарии
2 часов 1 минута назад
6 часов 17 минут назад
6 часов 27 минут назад
6 часов 32 минут назад
6 часов 52 минут назад
7 часов 1 минута назад