Безопасен ли тип Python?

Статья в Википедии связывает безопасный тип с безопасным для памяти, что означает, что к одной и той же области памяти нельзя получить доступ, например, целое число и строка. Таким образом, Python является типобезопасным. Вы не можете неявно изменить тип объекта.

Поскольку этого еще никто не сказал, стоит также отметить, что Python - это строго типизированный язык, который не следует путать с динамически типизированным. Python откладывает проверку типов до последнего возможного момента и обычно приводит к возникновению исключения. Это объясняет поведение, о котором упоминает Мюрейник. При этом Python также часто выполняет автоматическое преобразование. Это означает, что он попытается преобразовать int в float, например, для арифметической операции.

Вы можете вручную обеспечить безопасность типов в своих программах, проверив типы входных данных. Поскольку все является объектом, вы всегда можете создавать классы, производные от базовых классов, и использовать функцию isinstance для проверки типа (конечно, во время выполнения). Python 3 добавил подсказки типов, но это не применяется. И mypy добавил статическую проверку типа в язык, если вы хотите его использовать, но это не гарантирует тип безопасность.

Не в твоих самых смелых мечтах.

#!/usr/bin/python

counter = 100          # An integer assignment
miles   = 1000.0       # A floating point
name    = "John"       # A string

print counter
print miles
print name

counter = "Mary had a little lamb"

print counter

Когда вы запустите это, вы увидите:

python p1.py
100
1000.0
John
Mary had a little lamb

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

В реальном мире профессиональной разработки программного обеспечения под безопасным типом мы подразумеваем то, что компилятор улавливает глупые вещи. Да, в C / C ++ вы можете предпринять чрезвычайные меры для обхода безопасности типов. Вы можете объявить что-то вроде этого

union BAD_UNION
{
   long number;
   char str[4];
} data;

Но для этого программист должен сделать все возможное. Нам не пришлось тратить лишние дюймы, чтобы разделить переменную счетчика в python.

Программист может делать неприятные вещи с приведением типов в C / C ++, но они должны делать это намеренно; не случайно.

Единственное место, которое вас действительно обожжет, - это кастинг классов. Когда вы объявляете функцию / метод с параметром базового класса, а затем передаете указатель на производный класс, вы не всегда получаете нужные методы и переменные, потому что метод / функция ожидает базовый тип. Если вы переопределите что-либо из этого в производном классе, вы должны учесть это в методе / функции.

В реальном мире типобезопасный язык помогает защитить программиста от случайных глупостей. Он также защищает человеческий вид от смертельных случаев.

Рассмотрите возможность использования инсулиновой или инфузионной помпы. Что-то, что закачивает ограниченное количество спасающих / продлевающих жизнь химикатов в человеческий организм с желаемой скоростью / интервалом.

Теперь рассмотрим, что происходит, когда существует логический путь, в котором логическая схема управления шаговым двигателем помпы пытается интерпретировать инсулин в строке как целое количество для введения. Результат не будет хорошим. Скорее всего, это будет летальным исходом.

В Python вы получите ошибку времени выполнения, если используете переменную неправильного типа в неправильном контексте. Например.:

>>> 'a' + 1

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

Поскольку эта проверка выполняется только во время выполнения, а не перед запуском программы, Python не является типизированным языком (PEP-484 несмотря на это).

в общем, для крупномасштабных / сложных систем требуется проверка типов, сначала при типе компиляции (статический) и во время выполнения (динамический). это не научная наука, а скорее простое практическое правило здравого смысла, например, компилятор - ваш друг. Помимо влияния на производительность во время выполнения, есть и другие важные последствия, а именно:

3 оси масштабируемости:

1. время сборки (возможность спроектировать и изготовить безопасные системы в срок и бюджет)
2. время выполнения (очевидно)
3. поддерживать время (способность поддерживать (исправлять ошибки) и расширять существующие системы безопасным способом, как правило, путем рефакторинга)

единственный способ сделать безопасный рефакторинг - это полностью протестировать все (используйте разработку, управляемую тестами, или хотя бы модульное тестирование, а также хотя бы достойное тестирование покрытия, это не qa, это development / r & d). то, что не покрыто, сломается, и подобные системы - скорее мусор, чем инженерные артефакты.

Теперь предположим, что у нас есть простая функция sum, возвращающая сумму двух чисел. можно представить себе выполнение модульного тестирования этой функции, основываясь на том факте, что известны как параметры, так и возвращаемый тип. мы не говорим о шаблонах функций, которые сводятся к тривиальному примеру. напишите простой модульный тест для той же функции с именем sum, где параметры и возвращаемый тип могут быть буквально любого типа, они могут быть целыми числами, числами с плавающей запятой, строками и / или любыми другими типами, определяемыми пользователем, с перегруженным / реализованным оператором плюс . как написать такой простой тестовый пример?!? насколько сложным должен быть тестовый пример, чтобы охватить все возможные сценарии?

сложность означает стоимость. без надлежащего модульного тестирования и тестового покрытия не существует безопасного способа выполнить рефакторинг, поэтому продукт представляет собой мусор при обслуживании, не видимый сразу, ясно в долгосрочной перспективе, потому что выполнение любого рефакторинга вслепую было бы похоже на вождение автомобиля без водительских прав Пьяный, как скунс, и, конечно же, без страховки.

иди разбери! :-)

предположим, что у вас есть функция-сумма, принимая два аргумента, если аргументы не типизированы (может что угодно), тогда ... ну ... это неприемлемо для любого серьезного инженера-программиста, работающего над реальными большими системами, вот почему:

1. наивный ответ: компилятор - ваш друг. несмотря на то, что ему около 65 лет, это правда, и эй, дело не только в статических типах! ide (s) используют службы компилятора для множества вещей, которые для среднего программиста Джо выглядят как магия ... (завершение кода, помощь во время разработки (редактирование) и т. д.
2. o более реальная причина заключается в чем-то совершенно неизвестном разработчикам, не имеющим большого опыта в области компьютерных наук и, более того, в разработке программного обеспечения. Есть 3 оси масштабируемости: a. разработка / написание и развертывание, b. время выполнения и т. д. поддерживать время на основе рефакторинга. Как вы думаете, кто самый дорогой? явно повторяется в любой реальной серьезной системе? третий (с). чтобы удовлетворить (c), вам нужно сделать это безопасно. Для того, чтобы выполнить безопасный рефакторинг, вам необходимо пройти модульное тестирование И тестирование покрытия (чтобы вы могли оценить уровень покрытия, охватываемый вашим набором модульного тестирования) - помните, что когда что-то не тестируется автоматически, оно сломается (во время выполнения, в конце цикла, на сайте клиента, вы называете это) - Итак, чтобы иметь достойный продукт, вам нужно иметь достойное модульное тестирование и покрытие тестами

А теперь перейдем к нашей интеллектуальной функции (сумме). is sum (a, b) не указывает типы a и b, нет возможности провести достойное модульное тестирование. такие тесты, как assent sum (1,1), равны 2 IS ЛОЖЬ, потому что они не охватывают ничего, кроме предполагаемых целочисленных аргументов. в реальной жизни, когда a и b являются гермафродитами типа, тогда нет никакого способа написать реальное модульное тестирование против суммы функций! различные фреймворки даже делают вид, что получают результаты тестового покрытия из урезанных тестовых примеров, подобных описанному выше. это (очевидно) еще одна ЛОЖЬ.

это все, что я должен был сказать! спасибо за чтение, единственная причина, по которой я это опубликовал, это, возможно, для того, чтобы вы подумали об этом и, может быть (МОЖЕТ БЫТЬ ...) однажды заняться разработкой программного обеспечения ...

У нас только что произошла большая ошибка в фрагменте кода. Ошибка возникла из-за того, что у нас было следующее:

   if sys.errno:
        my_favorite_files.append(sys.errno)

вместо этого:

    if args.errno:
        my_favorite_files.append(sys.errno)

Агрессивное преобразование чего-либо в Boolean, потому что оно упрощает if операторы, - это то, чего я не ожидал найти в языке, который является типобезопасным.