Quando é necessário digitar .cast?

No esquema LEFT = RIGHT, se RIGHTnão for atribuível a LEFT, então ele "precisa de um cast"*.

Isso também se aplica ao tipo de retorno de uma função, da seguinte forma:

def f(...) -> <type of LEFT>:
    return RIGHT

Alguns exemplos gerais:

• RIGHTé um subtipo de LEFT- não precisa de cast:

  a: int | str = ""
  b: int | str | bytes = a
  
  class C: pass
  class D(C): pass
  c: C = D()
  

• RIGHTé um supertipo de LEFT- precisa de cast:

  from typing import cast
  
  a: object = ...
  b: str = cast(str, a)
  

• RIGHT não é um supertipo ou subtipo de LEFT- também precisa de cast:

  from typing import cast
  
  a: int = 1
  b: str = cast(str, a)
  

Quanto aos seus exemplos na pergunta:

• P : Na primeira linha de código, : strbasta dizer ao Pylance que sourceé uma string, embora args.sourceseja Any.

  Anyé tratado de forma especial no sistema de tipos. Da especificação de tipagem :

  Cada tipo é atribuível a Anye Anyé atribuível a cada tipo.

  Isso permite o seguinte sem cast:

  from typing import Any
  
  a: Any = 1
  b: str = a
  

• P : ... na segunda linha, quando adiciono : argparse.ArgumentParser, o tipo de analisador ainda é Any | argparse.ArgumentParser.

  Na verdade, isso é apenas uma peculiaridade do pyright/pylance. Quando o pyright pensa que você está fazendo algo errado em RIGHT, ele propaga um tipo Any(ou, na terminologia do próprio pyright, Unknown) para , LEFTmesmo que LEFTjá tenha uma anotação explícita (outros verificadores de tipo podem não fazer isso). Aqui está um reprodutor simples:

  a: int = THIS_NAME_IS_NOT_DEFINED
  reveal_type(a)  # pyright: Type of "a" is "Unknown | int"
  

  Quanto ao motivo pelo qual os direitos autorais acham que você está fazendo algo errado, há três problemas com seu snippet:

  1. subparsers: argparse._SubParsersActionNão é atribuído um valor; é apenas uma declaração. O Pyright detesta isso e pode até se recusar a ler quaisquer anotações.

     a: int
     reveal_type(a)  # pyright: Type of "a" is "Unknown"
     

  2. subparsers: argparse._SubParsersActionFalta um argumento de tipo na sua declaração de . Dos stubs da biblioteca padrão :

     # argparse.pyi
     
     ...
     _ArgumentParserT = TypeVar("_ArgumentParserT", bound=ArgumentParser)
     ...
     
     class _SubParsersAction(Action, Generic[_ArgumentParserT]):
         ...
     

     Você não deve usar esta anotação (ela é prefixada com um sublinhado); um trecho de código bem escrito e totalmente tipado usando , argparsenunca deve precisar usar anotações privadas de argparse, pois todos os tipos podem ser inferidos. No entanto, se você realmente quiser usar esta anotação, precisará fornecer um tipo concreto que seja limitado a argparse.ArgumentParser, como subparsers: argparse._SubParsersAction[argparse.ArgumentParser] = parser.add_subparsers(...). Este argumento de tipo é, na verdade, usado para resolver o tipo de retorno do add_parsermétodo , portanto, se você omiti-lo, o tipo de retorno será insolúvel.

  3. Sua chamada de "of" add_parserestá sem o primeiro argumento obrigatórioname . Novamente, o autor da frase não gosta disso e propaga um Unknown"to" LEFTse a sua expressão de chamada estiver errada:

     def get_int(a: int) -> int:
       return a 
     
     a: int = get_int()
     reveal_type(a)  # pyright: Type of "a" is "Unknown | int"
     

* É claro que, em algumas situações, você não "precisa de uma conversão" — uma anotação de tipo explícita junto com um # type: ignoreor # pyright: ignore[<some error code>]funcionará perfeitamente, além de ativar reportUnnecessaryTypeIgnoreCommento aviso para comentários de ignorar desnecessários. Isso evita a necessidade de uma consulta extra a variáveis ​​de tempo de execução e uma chamada para typing.cast.