Является ли Python строго типизированным?
я наткнулся на ссылки, которые говорят, что Python является строго типизированным языком.
однако я думал, что на строго типизированных языках вы не можете этого сделать:
bob = 1
bob = "bob"
Я думал, что сильно типизированный язык не принимает изменения типа во время выполнения. Возможно, у меня неправильное (или слишком упрощенное) определение сильных/слабых типов.
итак, является ли Python сильно или слабо типизированным языком?
10 ответов
Python-это динамически типизированный.
- сильный ввод означает, что тип значения не может измениться внезапно. Строка, содержащая только цифры, волшебным образом не становится числом, как это может произойти в Perl. Каждое изменение типа требует явного преобразования.
- динамический typing означает, что объекты среды выполнения (значения) имеют тип, в отличие от статического ввода, где переменные имеют тип.
Что касается вашего примера
bob = 1
bob = "bob"
это работает, потому что переменная не имеет типа; он может назвать любой объект. После bob=1, вы найдете, что type(bob) возвращает int, а после bob="bob" возвращает str. (Обратите внимание, что type является регулярной функцией, поэтому она оценивает свой аргумент, а затем возвращает тип значения.)
сравните это с более старыми диалектами C, которые были слабо, статически типизированы, так что указатели и целые числа были практически взаимозаменяемы. (Современный ISO C требует преобразований во многих случаях, но мой компилятор по-прежнему снисходителен к этому по умолчанию.)
Я должен добавить, что сильная и слабая типизация-это скорее континуум, чем логический выбор. C++ имеет более сильную типизацию, чем C (требуется больше преобразований), но система типов может быть свернута с помощью приведений указателей.
сила системы типов в динамическом языке, таком как Python, действительно определяется тем, как ее примитивы и библиотечные функции реагируют на различные типы. Е. Г., + перегружен так, что он работает на двух числах или две строки, но не строка и число. Это выбор дизайна, сделанный, когда + был реализован, но на самом деле не является необходимостью, вытекающей из семантики языка. На самом деле, при перегрузке + в пользовательском типе вы можете неявно преобразовать что-либо в число:
def to_number(x):
"""Try to convert x to a number."""
if x is None:
return 0
# more special cases here
else:
return float(x) # works for numbers and strings
class Foo(object):
def __add__(self, other):
other = to_number(other)
# now do the addition
(единственный язык, который я знаю, это полностью строго типизированный, он же строго типизированный, - это Haskell, где типы полностью непересекающиеся и возможна только контролируемая форма перегрузки через классы типов.)
есть некоторые важные вопросы, которые, я думаю, все существующие ответы пропустили.
слабая типизация означает предоставление доступа к базовому представлению. В C я могу создать указатель на символы, а затем сказать компилятору, что я хочу использовать его как указатель на целые числа:
char sz[] = "abcdefg";
int *i = (int *)sz;
на платформе little-endian с 32-битными целыми числами это делает i в массив чисел 0x64636261 и 0x00676665. На самом деле, вы даже можете бросить указателей сами к целым числам (соответствующего размера):
intptr_t i = (intptr_t)&sz;
и конечно, это означает, что я могу перезаписать память в любом месте в системе.*
char *spam = (char *)0x12345678
spam[0] = 0;
* конечно, современные ОС используют виртуальную память и защиту страниц, поэтому я могу только перезаписать память моего собственного процесса, но нет ничего о самом C, который предлагает такую защиту, как любой, кто когда-либо кодировал, скажем, классический Mac OS или Win16 может сказать вам.
традиционный Lisp разрешено подобное виды хакерства; на некоторых платформах поплавки с двойным словом и ячейки минусов были одного типа, и вы могли просто передать одну функцию ожидающей другой, и она "работала".
большинство языков сегодня не так слабы, как C и Lisp, но многие из них все еще несколько протекают. Например, любой язык OO, который имеет непроверенный "downcast",* это утечка типа: вы по существу говорите компилятору :" я знаю, что я не дал вам достаточно информации, чтобы знать, что это безопасно, но я уверен, что это," когда весь смысл системы типов заключается в том, что компилятор всегда имеет достаточно информации, чтобы знать, что это безопасно.
* проверенный downcast не делает систему типов языка слабее только потому, что она перемещает проверку во время выполнения. Если бы это было так, то полиморфизм подтипа (он же виртуальные или полностью динамические вызовы функций) был бы тем же нарушением системы типов, и я не думаю, что кто-то хочет это сказать.
очень мало "сценариев" в этом смысле языки слабы. Даже в Perl или TCL, вы не можете взять строку и просто интерпретировать байт как целое число.* Но стоит отметить, что в CPython (и аналогично для многих других переводчиков для многих языков), если вы действительно настойчивы, вы можете использовать ctypes загрузить libpython литой объекта id до POINTER(Py_Object), и принудите тип систему протекать. Делает ли это систему типов слабой или нет, зависит от ваших вариантов использования-если вы пытаетесь реализовать на языке ограниченное выполнение песочницы для обеспечения безопасности, вы должны иметь дело с этими видами побегов...
* вы можете использовать такую функцию, как struct.unpack для чтения байтов и создания нового int из "как C будет представлять эти байты", но это, очевидно, не протекает; даже Haskell позволяет это.
между тем, неявное преобразование действительно отличается от слабой или протекающей системы типа.
каждый язык, даже Haskell, имеет функции, скажем, преобразовать целое число в строку или поплавок. Но некоторые языки сделают некоторые из этих преобразований для вас автоматически-например, в C, если вы вызываете функцию, которая хочет float, и передать его в int, он преобразуется для вас. Это определенно может привести к ошибкам, например, неожиданным переполнениям, но это не те же ошибки, которые вы получаете от слабой системы типов. И C на самом деле не слабее здесь; вы можете добавить int и float в Haskell или даже объединить a float to a string, вам просто нужно сделать это более явно.
и с динамическими языками, это довольно мутной. В Python или Perl нет такой вещи, как "функция, которая хочет поплавок". Но есть перегруженные функции, которые делают разные вещи с разными типами, и есть сильное интуитивное чувство, что, например, добавление строки к чему-то другому-это "функция, которая хочет строку". В этом смысле Perl, Tcl и JavaScript, похоже, делают много неявных преобразований ("a" + 1 дает "a1"), в то время как Python делает много меньше ("a" + 1 вызывает исключение, но 1.0 + 1 не дает 2.0*). Это просто трудно выразить в формальных терминах-почему не должно быть + это принимает строку и int, когда есть, очевидно, другие функции, такие как индексирование, которые делают?
* на самом деле, в современном Python это можно объяснить с точки зрения подтипа OO, так как isinstance(2, numbers.Real) - это правда. Не думаю, что в этом есть какой-то смысл. 2 является экземпляром строкового типа в Perl или JavaScript... хотя в Tcl это действительно так, так как все является экземпляром string.
наконец, есть еще одно, полностью ортогональное определение" сильного "против" слабого "типа, где" сильный " означает мощный/гибкий/выразительный.
например, Haskell позволяет определить тип, который является числом, строкой, списком этого типа или сопоставлением строк с этим типом, который является идеальный способ представить все, что можно декодировать из JSON. Невозможно определить такой тип в Java. Но, по крайней мере, Java имеет параметрические (общие) типы, поэтому вы можете написать функцию, которая принимает список T и знает, что элементы имеют тип T; другие языки, такие как ранняя Java, заставили вас использовать список Object и downcast. Но, по крайней мере, Java позволяет создавать новые типы со своими собственными методами; C позволяет создавать только структуры. А у BCPL даже этого не было. И так далее до ... сборка, где единственными типами являются разные длины битов.
таким образом, в этом смысле система типов Хаскелла сильнее, чем современная Java, которая сильнее, чем более ранняя Java, которая сильнее, чем C, которая сильнее, чем BCPL.
Итак, где Python вписывается в этот спектр? Это немного сложно. Во многих случаях duck typing позволяет имитировать все, что вы можете сделать в Haskell, и даже некоторые вещи, которые вы не можете; конечно, ошибки ловятся во время выполнения вместо время компиляции, но они все еще пойманы. Тем не менее, есть случаи, когда Duck typing недостаточно. Например, в Haskell вы можете сказать, что пустой список ints - это список ints, поэтому вы можете решить, что уменьшение + список должен возвращать 0*; в Python, пустой список, пустой список, нет сведений о типе, чтобы помочь вам решить, что уменьшение + он должен делать.
* на самом деле, Haskell не позволяет вам это сделать; если вы вызываете функцию reduce это не принимает начальное значение в пустом списке, вы получаете ошибку. Но его тип системы достаточно мощный, что вы мог бы сделайте эту работу, а Python-нет.
Вы путаете 'strongly typed' С 'динамически'.
Я не могу изменить тип 1 добавить строку '12', но я могу выбрать, какие типы я храню в переменной и изменить это во время выполнения программы.
противоположностью динамической типизации является статическая типизация;объявление типов переменных не изменяется в течение жизни программы. Противоположность сильной типизации-слабая типизация; тип значения может изменяться в течение срока службы программы.
по этому wiki Python статья Python является динамически и строго типизированной (также дает хорошее объяснение).
возможно, вы думаете о статически типизированный языки, где типы не могут изменяться во время выполнения программы и проверка типов происходит во время компиляции для обнаружения возможных ошибок.
этот вопрос может представлять интерес:динамический тип языки против статического типа языки и эта статья Википедии о Системы Типа предоставляет больше информации
на него уже ответили несколько раз, но Python-это строго типизированный язык:
>>> x = 3
>>> y = '4'
>>> print(x+y)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
следующее в JavaScript:
var x = 3
var y = '4'
alert(x + y) //Produces "34"
в этом разница между слабой и сильной типизацией. Слабые типы автоматически пытаются преобразовать из одного типа в другой, в зависимости от контекста (например, Perl). Сильные типы никогда неявное преобразование.
ваша путаница заключается в непонимании того, как Python связывает значения с именами (обычно называют переменными).
в Python имена не имеют типов, поэтому вы можете делать такие вещи, как:
bob = 1
bob = "bob"
bob = "An Ex-Parrot!"
и имена могут быть привязаны ни к чему:
>>> def spam():
... print("Spam, spam, spam, spam")
...
>>> spam_on_eggs = spam
>>> spam_on_eggs()
Spam, spam, spam, spam
для дальнейшего чтения:
https://en.wikipedia.org/wiki/Dynamic_dispatch
и слегка связанные, но более продвинутые:
переменная Python хранит нетипизированную ссылку на целевой объект, представляющий значение.
любая операция присваивания означает присвоение нетипизированной ссылки назначенному объекту - т. е. объект совместно используется через исходные и новые (подсчитанные) ссылки.
тип значения привязан к целевому объекту, а не к ссылочному значению. Проверка типа (strong) выполняется при выполнении операции со значением (время выполнения).
в других слова, переменные (технически) не имеют типа - нет смысла думать в терминах типа переменной, если вы хотите быть точным. Но ссылки автоматически разыменовываются, и мы фактически думаем в терминах типа целевого объекта.
термин "сильная типизация" не имеет определенного определения.
таким образом, использование термина зависит от того, с кем вы говорите.
Я не считаю, что какой-либо язык, в котором тип переменной не объявлен явно или статически типизирован, должен быть строго типизирован.
сильная типизация не просто исключает преобразование (например," автоматическое " преобразование из целого числа в строку). Это исключает назначение (т. е. изменение тип переменной).
Если следующий код компилируется (интерпретируется), язык не является строго типизированным:
Foo = 1 Foo = "1"
на строго типизированном языке программист может "рассчитывать"на тип.
например, если программист видит декларации
UINT64 kZarkCount;
и он или она знает, что 20 строк спустя, kZarkCount по-прежнему является UINT64 (пока это происходит в том же блоке) - без необходимости исследовать промежуточный код.
TLDR;
Python набирает динамический таким образом, вы можете изменить переменную int на строку
x = 'somestring'
x = 50
Python набрав сильный таким образом, вы не можете объединить типы:
'x' + 3 --> TypeError: cannot concatenate 'str' and 'int' objects
в слабо типизированном Javascript это происходит...
'x'+3 = 'x3'
Относительно Вывода Типа
Java заставляет вас явно объявлять типы объектов
int x = 50
Котлин использует вывод, чтобы понять, что это int
x = 50
но поскольку оба языка используют статические типы,x не может быть изменен с int. Ни языка позволит динамический изменить как
x = 50
x = 'now a string'
Я думаю, этот простой пример должен объяснить различия между сильным и динамическим типом:
>>> tup = ('1', 1, .1)
>>> for item in tup:
... type(item)
...
<type 'str'>
<type 'int'>
<type 'float'>
>>>
java:
public static void main(String[] args) {
int i = 1;
i = "1"; //will be error
i = '0.1'; // will be error
}
class testme(object):
''' A test object '''
def __init__(self):
self.y = 0
def f(aTestMe1, aTestMe2):
return aTestMe1.y + aTestMe2.y
c = testme #get a variable to the class
c.x = 10 #add an attribute x inital value 10
c.y = 4 #change the default attribute value of y to 4
t = testme() # declare t to be an instance object of testme
r = testme() # declare r to be an instance object of testme
t.y = 6 # set t.y to a number
r.y = 7 # set r.y to a number
print(f(r,t)) # call function designed to operate on testme objects
r.y = "I am r.y" # redefine r.y to be a string
print(f(r,t)) #POW!!!! not good....
вышеизложенное создало бы кошмар недостижимого кода в большой системе в течение длительного периода времени. Называйте это как хотите, но возможность "динамически" менять тип переменных-это плохая идея...