Numpy: Digite hinting / annotation (PEP 484) para ndarray, dtype e ufunc

Criado em 2 mar. 2016  ·  70Comentários  ·  Fonte: numpy/numpy

Solicitação de recurso: suporte orgânico para PEP 484 com estruturas de dados Numpy.

Alguém implementou dicas de tipo para a classe específica numpy.ndarray?

No momento, estou usando a digitação. Qualquer, mas seria bom ter algo mais específico.

Por exemplo, se as pessoas numpy adicionaram um apelido de tipo para sua classe de objeto array_like. Melhor ainda, implemente o suporte no nível dtype, para que outros objetos sejam suportados, assim como o ufunc.

pergunta SO original

01 - Enhancement static typing

Comentários muito úteis

Eu queria cutucar novamente para ver se as discussões progrediram, especialmente em relação às informações de forma de sugestão de tipo, o que seria particularmente útil em muitos de meus aplicativos. Existe um rastreador de status ou esta não é uma prioridade alta o suficiente para ter recursos dedicados a ele?

Todos 70 comentários

Acho que ninguém pensou sobre isso. Talvez você queira? :-)

Também vou sugerir que, se você quiser dar continuidade a isso, fechemos o problema do gh e movamos a discussão para a lista de e-mails, já que é mais adequado para discussões abertas sobre design.

Depois de obter essa resposta no SO, decidi encerrar o problema.

Para ser claro, não temos nenhuma objeção ao suporte de novos recursos interessantes do Python ou qualquer coisa (ao contrário); é que somos um projeto executado por voluntários sem muitos recursos, então as coisas só acontecem se alguém interessado se apresentar para fazê-lo.

A lista de e-mails geralmente é o melhor lugar se você está tentando começar a trabalhar em algo ou espera recrutar outras pessoas interessadas para ajudar.

Obrigado, @njsmith. Decidi começar aqui por causa do rastreamento de problemas mais organizado, em oposição a uma lista de e-mails não estruturada (eu estava procurando por uma tag de 'solicitação de recurso', entre outros recursos ...)

Como o cara que me respondeu no SO me respondeu com uma solução viável, resolvi deixar o assunto.
Talvez a documentação do Numpy deva ser atualizada para incluir sua resposta (por favor, certifique-se de dar-lhe crédito se o fizer).

Obrigado novamente!

Ola pessoal! Eu estava apenas me perguntando se houve algum progresso nessa questão. Obrigado.

Há alguma discussão sobre isso na lista de discussão aqui .

Estou reabrindo esta edição para aqueles que estão interessados ​​em discuti-la mais profundamente.

Eu acho que isso seria certamente desejável para NumPy, mas existem alguns aspectos complicados da API NumPy para digitação e classificação, como a forma como NumPy atualmente aceita objetos arbitrários no construtor np.array (embora queiramos limpe isso, consulte https://github.com/numpy/numpy/issues/5353).

Um bom trabalho está sendo feito aqui: https://github.com/machinalis/mypy-data

Há uma discussão sobre se deve empurrar o trabalho para cima para numpy ou digitado: https://github.com/machinalis/mypy-data/issues/16

CC @mrocklin

Isso realmente seria um ótimo complemento para o NumPy. Quais seriam as próximas etapas para empurrar isso para formatado ou NumPy? Mesmo um esboço incompleto seria útil e estou feliz em ajudar com um pouco de orientação.

@henryJack O melhor lugar para começar provavelmente seria o ferramental: descubra como podemos integrar anotações de tipo básicas no repositório NumPy (e idealmente testá-las) de uma forma que funcione com mypy e ofereça suporte para adicioná-las de forma incremental.

Então, comece com anotações extremamente mínimas e podemos continuar a partir daí. Em particular, eu pularia as anotações dtype por enquanto, já que não temos uma boa maneira de especificá-las (ou seja, apenas ndarray , não ndarray[int] ).

Se for útil, tenho uma versão alternativa das anotações que escrevi para uso no Google e poderia abrir o código-fonte. Mas temos nosso próprio sistema de compilação exclusivo e fazemos a verificação de tipo com pytype , então provavelmente haveria peculiaridades ao portá-lo para o upstream.

Suponho que a única maneira de testar anotações para realmente executar mypy em fragmentos de código de amostra e verificar a saída?

Seria melhor ter as anotações integradas ao código ou como stubs separados?

Suponho que também devamos aprender com a caixa de depósito e os pandas que devemos começar com as folhas da base de código em relação às estruturas de dados principais.

@shoyer figure out how we can integrate basic type annotations
Não seria apenas colocar https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi no diretório base do módulo numpy fazer exatamente isso .. Em uma versão experimental de algum tipo finalmente

Seria melhor ter as anotações integradas ao código ou como stubs separados?

Integrado com o código seria ótimo, mas não acho que seja viável para o NumPy ainda. Mesmo com a versão da string de comentário das anotações de tipo, precisaríamos importar de typing no Python 2, e adicionar dependências ao NumPy está praticamente fora de questão.

Além disso, a maioria das principais estruturas de dados e funções (coisas como ndarray e array ) são definidas em módulos de extensão, precisaremos usar stubs lá de qualquer maneira.

Não seria apenas colocar https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi no diretório base do módulo numpy fazer exatamente isso .. Em uma versão experimental de algum tipo finalmente

Sim, acho que seria o suficiente para código externo. Mas como mypy lida com bibliotecas com anotações de tipo incompletas?

Se possível, podemos anotar numpy.core.multiarray diretamente, em vez de apenas no nível superior. ( multiarray é o módulo de extensão onde os tipos principais do NumPy, como ndarray são definidos.) Acho que isso permitiria ao próprio NumPy fazer uso da verificação de tipo para alguns de seus módulos Python puro.

Estou curioso, qual é o tipo de np.empty(shape=(5, 5), dtype='float32') ?

Qual é o tipo de np.linalg.svd ?

Parece que os tipos estão parametrizados, isso está com o dtype deles? Também é possível parametrizar com sua dimensão ou forma? Quanta sofisticação o módulo de digitação do Python suporta?

Sim, eles são parametrizados por seu tipo de d. Não sou especialista no módulo de digitação, mas acho que você poderia simplesmente fazer com que o tipo ndarray herde Generic[dtype, int] para parametrizar em ndim . Acho que é isso que Julia faz. Não tenho certeza se você poderia facilmente parametrizar a forma. Nem tenho certeza de quais benefícios isso traria ou por que não foi feito dessa forma em primeiro lugar.

Pode-se usar numpy dtypes no parâmetro dtype ou pode ser apenas digitação
tipos de módulo?

Também é estranho que numpy.empty retorne uma matriz do tipo Any. Eu suspeito
é um desafio interpretar e obter o tipo do valor dtype = palavra-chave?

Em 1 de setembro de 2017, 18:42, "Jacques Kvam" [email protected] escreveu:

Sim, eles são parametrizados por seu tipo de d. Não sou especialista em digitação
módulo, mas eu acho que você poderia simplesmente fazer com que o tipo ndarray herde Genérico [dtype,
int] para parametrizar no ndim. Acho que é isso que Julia faz. Eu não estou
claro se você pudesse facilmente parametrizar a forma. Nem tenho certeza do que
benefícios que trariam ou por que não foi feito, em primeiro lugar.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
.

Você pode usar dtypes numpy, só precisamos defini-los. Isso foi feito aqui com floating com np.std.

https://github.com/kjyv/mypy-data/blob/24ea87d952a98ef62680e812440aaa5bf49753ae/numpy-mypy/numpy/__init__.pyi#L198

Não tenho certeza, não acho que seja possível. Não acho que você possa modificar o tipo de saída com base no valor de um argumento. Acho que o melhor que podemos fazer é sobrecarregar a função com todas as especializações de tipo que nos interessam.

https://docs.python.org/3/library/typing.html#typing.overload

Outra opção pode ser introduzir alguns apelidos de tipo estrito, então np.empty[dtype] é uma função com assinatura (ShapeType) -> ndarray[dtype] .

Já existe algum precedente para isso com a função incomum np.cast[dtype](x)

@jwkvam OK, então talvez dtype anotações sejam viáveis ​​- eu estava apenas sugerindo começar de forma simples e ir daí.

Acho TypeVar possivelmente poderiam ser usados em vez de sobrecargas, talvez:

D = TypeVar('D', np.float64, np.complex128, np.int64, ...)  # every numpy generic type
def empty(dtype: Type[D]) -> ndarray[Type[D]]: ...

Se eu entendi corretamente, isso implicaria em empty(np.float64) -> ndarray[np.float64] .

Também seria incrível ser capaz de digitar as informações de formato e dimensionalidade de verificação, mas não acho que os verificadores de tipo atuais sejam adequados para a tarefa. Generic[int] é um erro, por exemplo - os argumentos para Generic devem ser instâncias de TypeVar :
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

Também precisaríamos expressar assinaturas envolvendo dimensões. Por exemplo, np.expand_dims maps ndim -> ndim+1 .

Suponho que uma abordagem que funcionaria seria definir classes para cada inteiro não negativo, por exemplo, Zero , One , Two , Three , .. e, em seguida, defina sobrecargas para cada um. Isso se cansaria muito rapidamente.

No TensorFlow, tf.Dimension() e tf.TensorShape() permitem expressar formas estaticamente. Mas não é algo feito no sistema de tipos. Em vez disso, cada função tem um auxiliar associado a ela que determina a forma estática das saídas a partir da forma das entradas e quaisquer argumentos não tensores. Acho que precisaríamos de algo semelhante se esperássemos fazer isso com o NumPy, mas não há nada no sistema de tipagem do Pythons que sugira esse tipo de flexibilidade.

@shoyer, eu vejo, sim, isso é decepcionante. Eu fui capaz de hackear o seguinte

_A = TypeVar('_A')
_B = TypeVar('_B', int, np.int64, np.int32)

class Abs(Generic[_A, _B]):
    pass

class Conc(Abs[_A, int]):
    pass

Mas eu não acho que isso está levando a lugar nenhum ...

Parece que seu exemplo funciona! Parecia que funcionava melhor sem as restrições de tipo. Eu poderia testar dtypes como str . Tive que remover o argumento padrão, não consegui descobrir como fazer isso funcionar.

D = TypeVar('D')
def empty(shape: ShapeType, dtype: Type[D], order: str='C') -> ndarray[D]: ...

e código

def hello() -> np.ndarray[int]:
    return np.empty(5, dtype=float)

eu recebo

error: Argument 2 to "empty" has incompatible type Type[float]; expected Type[int]

Estou um pouco confuso porque se eu trocar os tipos:

def hello() -> np.ndarray[float]:
    return np.empty(5, dtype=int)

Não recebo nenhum erro. Mesmo que eu não ache que nada esteja marcado como covariante.

Mesmo que o sistema de tipos não seja tão sofisticado quanto gostaríamos. Você acha que ainda vale a pena? Um benefício que eu apreciaria é um melhor preenchimento de código através do Jedi.

Estou um pouco confuso porque se eu trocar os tipos:

Eu acredito que o problema aqui é que int instâncias são implicitamente consideradas válidas para float anotações. Veja as notas na torre numérica no PEP de digitação:
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

Acho que isso poderia ser evitado se insistirmos em tipos escalares NumPy em vez de tipos genéricos de Python para anotações, por exemplo, np.ndarray[np.integer] vez de np.ndarray[int] .

Na verdade, isso é um pouco mais fácil do que eu pensava porque TypeVar tem um argumento bound . Então, revisando meu exemplo:

D = TypeVar('D', bound=np.generic)
def empty(dtype: Type[D]) -> ndarray[D]: ...

Tive que remover o argumento padrão, não consegui descobrir como fazer isso funcionar.

Não tenho certeza do que você estava querendo dizer?

Eu apenas tentei codificar o valor padrão de dtype no stub. Eles fizeram isso no repositório mypy-data.

def empty(shape: ShapeType, dtype: DtypeType=float, order: str='C') -> ndarray[Any]: ...

de https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi#L523

Seguindo seu exemplo, não consegui fazer com que mypy funcionasse com um argumento padrão para dtype. Tentei dtype: Type[D]=float e dtype: Type[D]=Type[float] .

Eu acho que dtype também precisa se tornar um tipo genérico, e então você precisa definir o valor padrão para uma subclasse genérica numpy como np.float64 vez de float , por exemplo,

# totally untested!
D = TypeVar('D', bound=np.generic)

class dtype(Generic[D]):
    <strong i="9">@property</strong>
    def type(self) -> Type[D]: ...

class ndarray(Generic[D]):
    <strong i="10">@property</strong>
    def dtype(self) -> dtype[D]: ...

DtypeLike = Union[dtype[D], D]  # both are coercible to a dtype
ShapeLike = Tuple[int, ...]

def empty(shape: ShapeLike, dtype: DtypeLike[D] = np.float64) -> ndarray[D]: ...

Isso não está certo. D == type(dtype.type) == type , então sua parametrização de tipo é inútil, pois o único parâmetro usado é D = type .

@ eric-wieser ops, acho que está consertado agora.

Houve alguma discussão relacionada ao rastreador de problemas do mypy (principalmente python / mypy # 3540). Lá, percebemos que o principal problema é que matrizes entorpecidas incluem conceitualmente suas dimensões em seu tipo, e o sistema de tipo atual realmente não suporta isso. Se os projetos mypy ou typeshed podem ajudar de alguma forma a fazer com que a digitação funcione para o numpy, por favor nos avise!

Houve alguma discussão relacionada ao rastreador de problemas do mypy (principalmente python / mypy # 3540). Lá, percebemos que o principal problema é que matrizes entorpecidas incluem conceitualmente suas dimensões em seu tipo, e o sistema de tipo atual realmente não suporta isso. Se os projetos mypy ou typeshed podem ajudar de alguma forma a fazer com que a digitação funcione para o numpy, por favor nos avise!

Eu poderia imaginar a codificação de mais ou menos informações em tipos parametrizados aqui. Por exemplo, uma matriz como np.empty((2, 3)) pode ser de qualquer um dos seguintes tipos:

  1. Array[float64, (2, 3)]
  2. Array[float64, (n, m)]
  3. Array[float64, ndim=2]
  4. Array[float64]
  5. Array

@JelleZijlstra qual é sua opinião aqui sobre quais ferramentas como o mypy provavelmente serão capazes de lidar? Quão sofisticados podemos ficar?

Parece bastante claro que um trabalho significativo no sistema de tipos seria necessário para dar suporte a formas e dimensionalidade. Eu acolheria isso (e apenas escrevi um monte de ideias em python / mypy # 3540), mas por enquanto vamos chamar isso fora do escopo para NumPy. Apenas fazer ndarray[float64] funcionar parece difícil o suficiente, dada a hierarquia de tipos complexos de numpy e os desafios dos tipos genéricos.

Sim, acho que o primeiro passo seria apenas obter suporte básico de digitação para numpy (e Pandas e sklearn) no, sem levar em consideração as formas e outras restrições extras nesses tipos.

O problema com outras restrições extras é que não é suficiente apenas descrever um tipo de d (forma = 5,6), mas deve haver uma linguagem para descrever uma restrição nessa forma. Você pode imaginar que deseja definir uma função que aceita apenas formas quadradas numpy como entradas, ou uma em que uma dimensão tem que ser 2x a outra.

Algo assim foi feito no projeto de contratos .

Eu também acho que o PEP 472 seria ótimo para apoiar aqui, porque então alguém poderia realmente fazer coisas como Array[float64, ndim=2] .

Na verdade, o PEP 472 seria bom para digitação, embora provavelmente seja uma das soluções mais fáceis de fazer isso acontecer! (Por favor, envie um ping se você estiver interessado em reiniciar a discussão sobre isso, pois acho que também existem casos de uso atraentes para dimensões nomeadas na indexação.)

Não tenho certeza de como posso contribuir, mas definitivamente acho que seria um recurso incrível por vários motivos. Mas, estamos indo nessa direção, então parece que [] se tornou uma maneira diferente de chamar um objeto. Então object(*args, **kwargs) faz alguma coisa, object[*args, **kwargs] outra coisa, e então podemos até generalizar e também ter object{*args, **kwags} e object<*args, **kwargs> . ;-)

@mitar : Olhando de outra forma, talvez devêssemos apenas anotar algo como ndarray[float].constrain(ndim=2) . Já temos muitas sintaxes disponíveis e, ao contrário dos decoradores, as anotações não têm restrições

Na verdade, tentei a seguinte sintaxe: ndarray[float](ndim=2) , portanto, sobrecarregar que nos genéricos __call__ retorna novamente uma classe, e não uma instância de uma classe. Mas ficou complicado para tipos que não são genéricos.

Acho que o principal problema é com o suporte de ndarray[float] , porque ndarray[float] não é algo que realmente existe em ndarray , seria necessário alterar o próprio ndarray , que Não tenho certeza se é um bom princípio geral a fazer (alterar o código upstream para oferecer suporte a uma melhor digitação).

Uma outra abordagem poderia ser ter um novo tipo de variáveis ​​de tipo, ConstrainedTypeVar , onde você poderia fazer algo como ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) ou algo parecido, e então você usaria A como um var na assinatura da função. Mas isso se torna muito prolixo.

Eu escrevi um documento com algumas idéias de como as formas de matriz de digitação poderiam ser com transmissão e uma noção de identidade de dimensão.

As ideias centrais incluem:

  1. Adicionando uma primitiva DimensionVar que permite identidades simbólicas para dimensões de array
  2. Reconhecendo ... ( Ellipsis ) como uma transmissão de matriz indicadora.

Por exemplo, para digitar np.matmul / @ :

from typing import DimensionVar, NDArray, overload

I = DimensionVar('I')
J = DimensionVar('J')
K = DimensionVar('K')

<strong i="17">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[..., J, K]) -> NDArray[..., I, K]: ...

<strong i="18">@overload</strong>
def matmul(a: NDArray[J], b: NDArray[..., J, K]) -> NDArray[..., K]: ...

<strong i="19">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[J]) -> NDArray[..., I]: ...

Isso seria suficiente para permitir a digitação de ufuncs generalizados . Consulte o documento para obter mais detalhes e exemplos.

Uma possível solução para suportar dtypes e formas, se já estivermos escolhendo manter NDArray e ndarray distintos:

NDArray[float].shape[I, J, K]
NDArray[float]
NDArray.shape[I, J, K]

Apenas um pensamento, faria sentido também ter um atalho como este?

NDArray.ndim[2]  # NDArray.shape[..., ...]
NDArray[float].ndim[2]  # NDArray[float].shape[..., ...]

- o que poderia simplificar várias assinaturas, especialmente no código downstream.

@aldanor Acho que você quer dizer NDArray.shape[:, :] ( ... significa "zero ou mais dimensões", o que não está certo neste contexto). Mas sim, isso parece razoável.


Rápida atualização sobre digitação para dtypes: Eu escrevi um módulo de brinquedo usando a abordagem que eu descrevi acima que os usos np.generic subclasses com Generic para parametrizado ndarray / dtype tipos .

Isso parece funcionar principalmente com mypy como eu esperava, incluindo inferência de tipo com o equivalente a np.empty(..., dtype=np.float32) . Ele não consegue detectar um dos meus erros de tipo intencionais envolvendo um tipo Union (vou apresentar um relatório de bug mais tarde).

Eu acho que isso provavelmente seria bom o suficiente para dtypes. Sem suporte de digitação para valores literais, não poderíamos fazer inferência de tipo com dtype especificado como strings ( dtype='float32' ). Talvez mais problemático, ele também não lida com a inferência de tipo de tipos Python como dtype=float . Mas esses tipos podem ser ambíguos (por exemplo, dtype=int mapeia para np.int64 no Linux e np.int32 no Windows), então provavelmente é melhor usar tipos genéricos explícitos de qualquer maneira. Tudo bem se a inferência de tipo não funcionar em todos os casos possíveis, desde que as especificações dtype=float sejam inferidas como um tipo de Any vez de gerar um erro.

Mas esses tipos podem ser ambíguos (por exemplo, dtype = int mapeia para np.int64 no Linux e np.int32 no Windows)

Isso não é ambíguo - em todos os casos, isso mapeia para np.int_ , que é o tipo C long .

Eu escrevi a lista de e-mails para obter consenso sobre como escrever stubs de tipo para o NumPy em um pacote separado:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

Incrível, obrigado @shoyer !

De acordo com o consenso na lista de e-mails, gostaria de declarar https://github.com/numpy/numpy_stubs aberto para negócios!

Começaremos com anotações básicas (sem suporte a dtype). Se alguém quiser montar um PR básico para adicionar o andaime PEP 561 para o repo, agradecemos!

SIM, SIM, 1000X SIM!

Alerta para quem está acompanhando este problema: Eu abri dois problemas no rastreador python / digitação:

  • ndarray digitação em geral (https://github.com/python/typing/issues/513)
  • sintaxe para digitação ndarray (https://github.com/python/typing/issues/516)

Qual é o tempo de liberação esperado para o recurso de digitação?
Há algum motivo para tentar manter a compatibilidade do 2.7?
Um comentário anterior mencionou a dificuldade de integração com o python 2. Desde então, parece que o numpy mudou de postura.

As coisas são alvos móveis, eu sei, mas faria sentido almejar algo como Python 3.4-3.6?

Qual é o tempo de liberação esperado para o recurso de digitação?

Houve várias discussões sobre isso (genéricos inteiros, também conhecidos como tipos dependentes simples) na PyCon, irei escrever um proto-PEP baseado nessas discussões e no documento original escrito por @shoyer em breve. Meu objetivo é fazer com que o PEP seja escrito, implementado em mypy e aceito a tempo para Python 3.8 beta 1 (também é muito provável que haja backport subsequente dos novos tipos em typing para Python 2)

@hmaarrfk quanto a escrever anotações de tipo para o NumPy em si, começamos a fazer isso em um repositório separado: https://github.com/numpy/numpy-stubs. Você deve conseguir instalar e usar esses stubs no estado atual (com a versão mais recente do mypy), mas eles estão longe de estar completos. A ajuda seria apreciada!

Claro, fico feliz em ajudar onde posso e vi o repositório. Só sei que essas coisas levam tempo.
Eu vi o repo e notei um commit mencionando a compatibilidade 2.7, por isso eu perguntei.

O lançamento da versão beta do Python 3.8 é em meados de 2019 . Numpy mencionou que iria parar de novos recursos no final de 2018 .

Digitar parece ser um recurso "bom de se ter" para o numpy, ao contrário de um "indispensável". Assim, almejar dois idiomas parece um pouco difícil, especialmente se o recurso começar a aparecer muito além do prazo de suporte do próprio numpy.

Terei interesse em ler o que @ilevkivskyi tem a dizer sobre o PEP.

@hmaarrfk Você levantou um bom ponto sobre o suporte ao Python 2.7. Para ser honesto, ainda não pensei muito sobre isso. Espero que eventualmente o abandonemos, mas provavelmente não antes que o próprio mypy abandone o suporte ao Python 2.7, visto que um importante caso de uso para digitação é escrever código compatível com Python 2/3.

Por enquanto, não parece exigir muitos compromissos para oferecer suporte a Python 2 em nossas anotações de tipo, então estou feliz em deixá-lo, especialmente porque veio de um contribuidor que estava evidentemente interessado nele.

Eu queria cutucar novamente para ver se as discussões progrediram, especialmente em relação às informações de forma de sugestão de tipo, o que seria particularmente útil em muitos de meus aplicativos. Existe um rastreador de status ou esta não é uma prioridade alta o suficiente para ter recursos dedicados a ele?

Em transonic , um projeto para generalizar aceleradores numpy, temos uma sintaxe de sugestão de tipo como uma alternativa para anotações Pythran que usa comentários . Não funciona bem com mypy agora, mas me pergunto se é útil. Veja um exemplo: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

Caso seja útil para este problema, mencionarei que criei uma ferramenta para converter docstrings em comentários do tipo: https://pypi.org/project/doc484/

Eu uso isso com pré-commit em vários projetos para manter docstrings em sincronia com comentários de tipo.

Você ainda precisará converter os tipos em suas docstrings para serem compatíveis com PEP484.

Olá a todos,

Eu queria fazer minha parte, então fiz um fork do repositório e comecei a adicionar dicas de tipo. Minha ideia era trabalhar de baixo para cima, então comece com as funções "simples" e vá subindo a partir daí. (Começando com as frutas mais baixas)

Por exemplo, em _string_helpers.py , adicionei dicas de tipo a algumas variáveis ​​e funções.

LOWER_TABLE: str = "".join(_all_chars[:65] + _ascii_lower + _all_chars[65 + 26:])
UPPER_TABLE: str = "".join(_all_chars[:97] + _ascii_upper + _all_chars[97 + 26:])

def english_lower(s: str) -> str:
    """ Apply English case rules to convert ASCII strings to all lower case.
   ...
    """
    lowered = s.translate(LOWER_TABLE)
    return lowered

O que você pensa sobre isso?

Eu recomendo fazer um pouco e abrir um PR para obter comentários. O numpy tem como alvo os pythons mais antigos (anotações introduzidas no 3.5, IIRC) e isso quebraria essas compilações, então talvez dê uma olhada em escrever arquivos .pyi ou verifique os documentos do mypy para ver se há um pouco mais de orientação sobre as melhores práticas.

Temos feito anotações até agora em tocos de números separados
repositório, mas tem sido um processo lento.

Na quinta-feira, 14 de novembro de 2019 às 9h57, Ben Samuel [email protected] escreveu:

Eu recomendo fazer um pouco e abrir um PR para obter comentários. entorpecido
tem como alvo pythons mais antigos (3,5 anotações introduzidas, IIRC) e este
quebraria essas compilações, então talvez você queira escrever arquivos .pyi ou verificar
os documentos do mypy para ver se há um pouco mais de orientação sobre as práticas recomendadas.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEECDL4A#issuecomment-553924080 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

@ bsamuel-ui numpy atualmente requer Python 3.5+, e o NEP-29 [1] afirma que não há problema em aumentá-lo para 3.6+
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

Na verdade, as anotações (para argumentos de função e tipos de retorno) são suportadas em todas as versões do Python 3; 3.6 introduziu apenas anotações de variáveis. Na versão inicial do Python 3 (<3.5), você deve usar um backport do módulo typing .

Eu adicionei uma solicitação de pull com meu primeiro arquivo .pyi. Precisa de algum trabalho, mas seria bom se vocês pudessem dar uma olhada para que eu possa obter alguns comentários iniciais

Conforme mencionado em gh-14905, temos o início de uma biblioteca stub em https://github.com/numpy/numpy-stubs. Seria ótimo fazer isso com testes adequados e então poderíamos decidir a melhor forma de empacotá-lo ou mesclá-lo em numpy / numpy adequado.

Meu mau @mattip. Vou remover a solicitação de pull de numpy e adicionar um novo a numpy-stubs

ainda está aberto, mas acredito que o numpy já suporta isso na versão master

Oi,
Estou tentando definir um alias de tipo para o vetor 3d, portanto, uma matriz numpy de forma (3) de dtype int32.

(Eu sei que posso digitar hint com np.ndarray, mas como posso ser mais específico? Li tudo aqui e não entendi, também procuro um tutorial sobre como usar tipos numpy para digitar em Python, mas não encontre qualquer coisa.)

Como é possível escrever:

from typing import Tuple
VectorType = Tuple[int, int, int]

Eu tentei fazer:

VectorType = np.ndarray(shape=(3,), dtype=np.int32)

É a maneira correta de fazer?

Alguém aqui pode me indicar um tutorial ou um exemplo, por favor?

Além disso, encontrei este repo que é "Digitar dicas para Numpy": https://github.com/ramonhagenaars/nptyping

O Numpy integrará isso?
@ramonhagenaars

@mattip

Conforme mencionado em gh-14905, temos o início de uma biblioteca stub em https://github.com/numpy/numpy-stubs.

Parece que isso foi mesclado no repositório principal. Isso foi lançado ou está no roteiro? Tentar decidir se devemos explorar algo de terceiros, como https://github.com/ramonhagenaars/nptyping ou (de preferência) esperar / usar dicas de tipo oficialmente suportadas.

Obrigado.

Nós mesclamos muitos dos numyp-stubs no branch de desenvolvimento. Você pode acompanhar o progresso procurando o rótulo de digitação estática . Esperançosamente, isso fará parte do próximo lançamento. Você pode experimentar o que está atualmente mesclado usando uma versão HEAD do numpy. Estamos sempre procurando por colaboradores: revisão construtiva, documentação e comentários sobre os problemas e solicitações de pull são algumas maneiras de ajudar.

(Eu sei que posso digitar hint com np.ndarray, mas como posso ser mais específico? Li tudo aqui e não entendi, também procuro um tutorial sobre como usar tipos numpy para digitar em Python, mas não encontre qualquer coisa.)

Há muito interesse nesta área, mas a tipagem mais específica (dtypes e dimensões) para arrays NumPy ainda não é suportada.

Esta página foi útil?
0 / 5 - 0 avaliações