Adnotacja typu powrotu void w języku Python

W Pythonie 3.x często używa się adnotacji typu zwracanego funkcji, takich jak:

def foo() -> str:
    return "bar"

Jaka jest prawidłowa adnotacja dla typu „void”?

Rozważam 3 opcje:

1. def foo() -> None:
   • nie logiczne IMO, ponieważ Nonenie jest typem,
2. def foo() -> type(None):
   • używając najlepszej znanej mi składni do uzyskania NoneType,
3. def foo():
   • pomiń jawne informacje o zwracanym typie.

Opcja 2. wydaje mi się najbardziej logiczna, ale widziałem już kilka przykładów 1.

To pochodzi prosto z dokumentacji PEP 484 - Wskazówki dotyczące typów :

W przypadku użycia w wskazówce dotyczącej typu wyrażenie Nonejest traktowane jako równoważne type(None).

Jak widać, większość przykładów używa Nonejako typu zwracanego.

TLDR: idiomatyczny odpowiednik voidadnotacji typu zwracanego to -> None.

def foo() -> None:
    ...

Ten odpowiada, że funkcja bez returnlub tylko gołe returnma wartość None.

def void_func():  # unannotated void function
    pass

print(void())  # None

Pominięcie zwracanego typu nie oznacza, że ​​nie ma zwracanej wartości. Zgodnie z PEP 484 :

W przypadku funkcji zaznaczonej domyślną adnotacją dla argumentów i dla typu zwracanego jest Any.

Oznacza to, że wartość jest uważana za wpisaną dynamicznie i statycznie obsługuje każdą operację . To jest praktycznie przeciwne znaczenie void.

Podpowiedzi do typów w Pythonie nie wymagają ściśle określonych typów. Na przykład, adnotacje mogą używać ciągów nazw typu: Union[str, int], Union[str, 'int'], 'Union[str, int]'i różne warianty są równoważne.

Podobnie Noneuważa się , że adnotacja typu oznacza „jest z NoneType”. Można to wykorzystać nie tylko w przypadku typów zwracanych, chociaż zobaczysz to najczęściej:

bar : None

def foo(baz: None) -> None:
    return None

Dotyczy to również typów ogólnych. Na przykład można użyć Nonein, Generator[int, None, None]aby wskazać, że generator nie przyjmuje ani nie zwraca wartości.

Mimo że PEP 484 sugeruje, że Noneto oznacza type(None), nie należy jawnie używać tej drugiej formy. Specyfikacja podpowiedzi typu nie obejmuje żadnej formy type(...). Jest to technicznie wyrażenie środowiska uruchomieniowego, a jego obsługa zależy wyłącznie od sprawdzania typów. mypyProjekt rozważa usunięcie wsparcia dla type(None)i usunąć go z 484, jak również.

A może powinniśmy zaktualizować PEP 484, aby nie sugerował, że type(None)jest ważny jako typ i Nonejest jedyną poprawną pisownią? Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na zrobienie tego itp.

--- JukkaL, 18 maja 2018 r