Jak/dlaczego działa podpowiedź typu Python?

Question

Właśnie widziałem następujący przykład w PEP 484:

def greeting(name: str) -> str: 
    return 'Hello ' + name 

print(greeting('Martin')) 
print(greeting(1)) 

Zgodnie z oczekiwaniami, to nie działa w Pythonie 2:

File "test.py", line 1 
    def greeting(name: str) -> str: 
        ^
SyntaxError: invalid syntax 

jednak, że pracuje dla Python 3:

Hello Martin 
Traceback (most recent call last): 
    File "test.py", line 5, in <module> 
    print(greeting(1)) 
    File "test.py", line 2, in greeting 
    return 'Hello ' + name 
TypeError: Can't convert 'int' object to str implicitly 

To było nieoczekiwane. To naprawdę nie ma sprawdzić typy jeszcze, jak widać z poniższego przykładu (to działa, ale nie wyjątek):

def greeting(name: str) -> int: 
    return 'Hello ' + name 

print(greeting('Martin')) 

Wydaje się, że po : musi być nazwa funkcji , ale funkcja wydaje się być ignorowane:

def aha(something): 
    print("aha") 
    return something+"!" 

def greeting(name: aha, foo) -> int: 
    return 'Hello ' + name + foo 

print(greeting('Martin', 'ad')) 

To samo wydaje się być prawdziwe nazwy po ->.

Czy ten typ podpowiedzi składni używa czegoś innego (np. Język Java Modeling korzysta z komentarzy)? Kiedy ta składnia została wprowadzona do Pythona? Czy istnieje sposób sprawdzania statycznego już przy użyciu tej składni? Czy zawsze łamie kompatybilność z Pythonem 2?

Answer 1

Nie ma tu żadnego rodzaju podpowiedzi. Wszystko, co zrobiłeś, to dostarczyć adnotacje; zostały one wprowadzone z PEP 3107 (tylko w Pythonie 3 nie ma na to wsparcia w Pythonie 2); Pozwalają one opisywanie argumenty i zwracać wartości z dowolnego informacji do późniejszego wglądu:

>>> greeting.__annotations__ 
{'name': <class 'str'>, 'return': <class 'str'>} 

one inaczej nie konsultowany w ogóle tutaj. Zamiast tego, komunikat o błędzie masz to od próbując złączyć ciąg i całkowitą wartości w ciele funkcji:

>>> 'Hello ' + 1 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
TypeError: Can't convert 'int' object to str implicitly 

Jest to błąd niestandardowy typ na celu dostarczenie dodatkowych informacji, dlaczego str + int konkatenacja nie powiodła się; to jest wyrzucane metodą str.__add__ dla dowolnego typu, który nie jest str:

>>> ''.__add__(1) 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
TypeError: Can't convert 'int' object to str implicitly 
>>> ''.__add__(True) 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
TypeError: Can't convert 'bool' object to str implicitly 

PEP 484 następnie proponuje, aby korzystanie z tych adnotacji zrobić rzeczywisty statyczny typ kontroli z dodatkowych narzędzi, ale jako wprowadzenia euro PEP stwierdza:

Chociaż te adnotacje są dostępne w czasie wykonywania przez zwykłego atrybutu __annotations__, bez sprawdzania typ dzieje w czasie wykonywania. Zamiast tego wniosek zakłada istnienie odrębnego sprawdzania typu, który użytkownicy mogą dobrowolnie przeszukiwać swoim kodem źródłowym. Zasadniczo taki sprawdzian typu działa jak bardzo mocny linter.

Podkreślenie w oryginale.

PEP został zainspirowany istniejącymi narzędziami wykorzystującymi adnotacje PEP 3107; konkretnie mypy project (który zapętla się z powrotem, przyjmując PEP 484), ale także type hinting support in the PyCharm IDE i pytypedecl project. Zobacz: Guido van Rossuma: original email kickstarting this effort, a także follow-up email.

mypy najwyraźniej obsługuje Python 2 poprzez przerób adnotacje, usuwając je przed bajt kompilacji kodu źródłowego dla ciebie, ale inaczej nie można normalnie korzystać z kodu składni Pythona oznaczało pracować w Pythonie 2.

PEP 484 również opisuje użycie stub files, które znajdują się obok zwykłych plików Pythona; używają one rozszerzenia .pyi i zawierają jedynie sygnatury (z podpowiedziami typu), pozostawiając główną informację o plikach .py i tym samym użyteczną na Pythonie 2 (pod warunkiem, że napisałeś kod Polyglot Python w innym przypadku).