Numpy: Escriba sugerencias / anotaciones (PEP 484) para ndarray, dtype y ufunc

Creado en 2 mar. 2016  ·  70Comentarios  ·  Fuente: numpy/numpy

Solicitud de función: soporte orgánico para PEP 484 con estructuras de datos Numpy.

¿Alguien ha implementado sugerencias de tipo para la clase numpy.ndarray específica?

En este momento, estoy usando la escritura. Cualquiera, pero sería bueno tener algo más específico.

Por ejemplo, si el número de personas agregó un alias de tipo para su clase de objeto array_like. Mejor aún, implemente el soporte en el nivel dtype, para que otros objetos sean compatibles, además de ufunc.

pregunta SO original

01 - Enhancement static typing

Comentario más útil

Quería tocar esto nuevamente para ver si las discusiones han progresado, especialmente con respecto a la información de forma de sugerencia de tipo, que sería particularmente útil en muchas de mis aplicaciones. ¿Existe un rastreador de estado o no es una prioridad lo suficientemente alta como para tener recursos dedicados a él?

Todos 70 comentarios

No creo que nadie haya pensado en eso. ¿Quizás te gustaría? :-)

También voy a sugerir que, si quieres dar seguimiento a esto, cerremos el problema de gh y movemos la discusión a la lista de correo, ya que se adapta mejor a las discusiones de diseño abiertas.

Después de obtener esta respuesta sobre SO, decidí cerrar el problema.

Para ser claros, en realidad no tenemos ninguna objeción a admitir nuevas características geniales de Python ni nada (más bien todo lo contrario); es solo que somos un proyecto dirigido por voluntarios sin muchos recursos, por lo que las cosas solo suceden si alguien que está interesado se acerca para hacerlo.

La lista de correo suele ser el mejor lugar si está tratando de comenzar a trabajar en algo o si espera reclutar a otras personas interesadas para ayudar.

Gracias, @njsmith. Decidí comenzar aquí debido al seguimiento más ordenado de los problemas, a diferencia de una lista de correo no estructurada (estaba buscando una etiqueta de 'solicitud de función', entre otras características ...)

Dado que el tipo que me respondió en SO me respondió con una solución viable, decidí dejar el asunto.
Tal vez la documentación de Numpy debería actualizarse para incluir su respuesta (asegúrese de darle crédito si lo hace).

¡Gracias de nuevo!

¡Hola chicos! Me preguntaba amablemente si había habido algún progreso en este tema. Gracias.

Hay algo de discusión al respecto en la lista de correo aquí .

Reabriré este número para aquellos que estén interesados ​​en seguir discutiendo.

Creo que esto sin duda sería deseable para NumPy, pero de hecho hay algunos aspectos complicados de la API de NumPy para clasificar, como cómo NumPy actualmente acepta objetos arbitrarios en el constructor np.array (aunque queremos limpiar esto, consulte https://github.com/numpy/numpy/issues/5353).

Aquí se está haciendo un buen trabajo: https://github.com/machinalis/mypy-data

Hay una discusión sobre si impulsar el trabajo corriente arriba a numpy o mecanografiado: https://github.com/machinalis/mypy-data/issues/16

CC @mrocklin

Esto realmente sería una gran adición a NumPy. ¿Cuáles serían los próximos pasos para impulsar esto a mecanografiado o NumPy? Incluso un talón incompleto sería útil y estoy feliz de ayudar con un poco de dirección.

@henryJack El mejor lugar para comenzar probablemente sea con las herramientas:

Luego, comience con anotaciones extremadamente mínimas y podemos continuar desde allí. En particular, omitiría las anotaciones dtype por ahora, ya que no tenemos una buena manera de especificarlas (es decir, solo hacer ndarray , no ndarray[int] ).

Si es útil, tengo una versión alternativa de las anotaciones que escribí para usar en Google y podría ser de código abierto. Pero tenemos nuestro propio sistema de compilación único y verificamos los tipos con pytype , por lo que es probable que haya peculiaridades al migrarlo hacia arriba.

Supongo que la única forma de probar las anotaciones es ejecutar mypy en fragmentos de código de muestra y verificar el resultado.

¿Sería mejor tener las anotaciones integradas con el código o como apéndices separados?

Supongo que también deberíamos aprender de Dropbox y pandas que deberíamos comenzar con las hojas del código base versus las estructuras de datos centrales.

@shoyer figure out how we can integrate basic type annotations
No solo poner https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi en el directorio base del módulo numpy haría exactamente eso .. En una versión experimental de algún tipo al menos

¿Sería mejor tener las anotaciones integradas con el código o como apéndices separados?

Integrarlo con el código sería encantador, pero no creo que sea factible para NumPy todavía. Incluso con la versión de cadena de comentarios de las anotaciones de tipo, necesitaríamos importar desde typing en Python 2, y agregar dependencias a NumPy está bastante fuera de la mesa.

Además, la mayoría de las estructuras y funciones de datos centrales (cosas como ndarray y array ) están definidas en módulos de extensión, de todos modos necesitaremos usar stubs.

No solo poner https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi en el directorio base del módulo numpy haría exactamente eso .. En una versión experimental de algún tipo al menos

Sí, creo que sería suficiente para el código externo. Pero, ¿cómo maneja mypy las bibliotecas con anotaciones de tipo incompletas?

Si es posible, podríamos anotar numpy.core.multiarray directamente, en lugar de solo en el nivel superior. ( multiarray es el módulo de extensión donde se definen los tipos centrales de NumPy como ndarray .) Creo que esto le permitiría a NumPy hacer uso de la verificación de tipos para algunos de sus módulos de Python puro.

Tengo curiosidad, ¿cuál es el tipo de np.empty(shape=(5, 5), dtype='float32') ?

¿Cuál es el tipo de np.linalg.svd ?

Parece que los tipos están parametrizados, ¿es esto con su dtype? ¿También es factible parametrizar con su dimensión o forma? ¿Cuánta sofisticación admite el módulo de mecanografía de Python?

Sí, están parametrizados por su dtype. No soy un experto en el módulo de escritura, pero creo que podría hacer que el tipo ndarray herede Generic[dtype, int] para parametrizar en ndim . Creo que eso es lo que hace Julia. No estoy seguro de si podría parametrizar fácilmente la forma. Tampoco estoy seguro de los beneficios que traería o por qué no se hizo de esa manera en primer lugar.

¿Se puede usar numpy dtypes en el parámetro dtype o solo se puede escribir?
tipos de módulo?

También es extraño que numpy.empty devuelva una matriz de tipo Any. Sospecho
¿Es un desafío intercalar y tomar el tipo del valor de palabra clave dtype =?

El 1 de septiembre de 2017 a las 6:42 p.m., "Jacques Kvam" [email protected] escribió:

Sí, están parametrizados por su dtype. No soy un experto en escribir
módulo, pero creo que podría hacer que el tipo ndarray heredara Generic [dtype,
int] para parametrizar en ndim. Creo que eso es lo que hace Julia. no soy
Seguro que puedes parametrizar fácilmente la forma. Ni estoy seguro de que
beneficios que traería o por qué no se hizo ese por qué en primer lugar.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
.

Puede usar numpy dtypes, solo necesitamos definirlos. Eso se hizo aquí con floating con np.std.

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

No estoy seguro, no creo que sea posible. No creo que pueda modificar el tipo de salida en función del valor de un argumento. Creo que lo mejor que podemos hacer es sobrecargar la función con todas las especializaciones de tipos que nos interesarían.

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

Otra opción podría ser introducir algunos alias de tipo estricto, por lo que np.empty[dtype] es una función con la firma (ShapeType) -> ndarray[dtype] .

Ya hay un precedente para esto con la función inusual np.cast[dtype](x)

@jwkvam OK, entonces tal vez las anotaciones dtype sean factibles; solo estaba sugiriendo comenzar de manera simple e ir desde allí.

Creo que TypeVar posiblemente podría usarse en lugar de sobrecargas, tal vez:

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

Si entiendo esto correctamente, esto implicaría empty(np.float64) -> ndarray[np.float64] .

También sería increíble poder escribir la información de forma y dimensionalidad de cheques, pero no creo que los verificadores de tipos actuales estén a la altura. Generic[int] es un error, por ejemplo: los argumentos de Generic deben ser instancias de TypeVar :
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

También necesitaríamos expresar firmas que involucren dimensiones. Por ejemplo, np.expand_dims mapas ndim -> ndim+1 .

Supongo que un enfoque que funcionaría es definir clases para cada entero no negativo, por ejemplo, Zero , One , Two , Three , .. .y luego defina las sobrecargas para cada uno. Eso se cansaría muy rápidamente.

En TensorFlow, tf.Dimension() y tf.TensorShape() te permiten expresar formas estáticamente. Pero no es algo que se haga en el sistema de tipos. Más bien, cada función tiene un ayudante asociado que determina la forma estática de las salidas a partir de la forma de las entradas y cualquier argumento no tensorial. Creo que necesitaríamos algo similar si quisiéramos hacer esto con NumPy, pero no hay nada en el sistema de escritura de Pythons que sugiera este tipo de flexibilidad.

@shoyer Ya veo, sí, eso es decepcionante. Pude hackear lo siguiente

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

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

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

Pero no creo que eso lleve a ninguna parte ...

¡Parece que tu ejemplo funciona! Parecía que funcionaba mejor sin las limitaciones de tipo. Podría probar dtypes como str . Tuve que eliminar el argumento predeterminado, no pude averiguar cómo hacer que funcione.

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

y codigo

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

yo obtengo

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

Estoy un poco confundido porque si cambio los tipos:

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

No obtengo ningún error. Aunque no creo que nada esté marcado como covariante.

Aunque el sistema de tipos no es tan sofisticado como nos gustaría. ¿Crees que todavía vale la pena? Un beneficio que agradecería es una mejor finalización del código a través de jedi.

Estoy un poco confundido porque si cambio los tipos:

Creo que el problema aquí es que las instancias int se consideran implícitamente válidas para las anotaciones float . Vea las notas en la torre numérica en el PEP de escritura:
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

Creo que esto podría evitarse si insistimos en los tipos escalares NumPy en lugar de los tipos genéricos de Python para las anotaciones, por ejemplo, np.ndarray[np.integer] lugar de np.ndarray[int] .

En realidad, esto es un poco más fácil de lo que pensaba porque TypeVar tiene un argumento bound . Entonces revisando mi ejemplo:

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

Tuve que eliminar el argumento predeterminado, no pude averiguar cómo hacer que funcione.

No estoy muy seguro de a qué te refieres aquí.

Intenté codificar el valor predeterminado de dtype en el stub. Lo hicieron en el repositorio 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

Siguiendo su ejemplo, no pude hacer que mypy funcionara con un argumento predeterminado para dtype. Probé dtype: Type[D]=float y dtype: Type[D]=Type[float] .

Creo que dtype también debe convertirse en un tipo genérico, y luego debe establecer el valor predeterminado en una subclase genérica numpy como np.float64 lugar de float , por ejemplo,

# 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]: ...

Eso no está bien. D == type(dtype.type) == type , por lo que su parametrización de tipo es inútil, ya que el único parámetro utilizado es D = type .

@ eric-wieser oops, creo que ya está arreglado.

Ha habido una discusión relacionada sobre el rastreador de problemas de mypy (python / mypy # 3540 principalmente). Allí, percibimos que el problema principal es que los arreglos numéricos incluyen conceptualmente sus dimensiones en su tipo, y el sistema de tipos actual realmente no lo admite. Si los proyectos mypy o mecanografiado pueden ayudar de alguna manera a que la escritura funcione para numpy, ¡háganoslo saber!

Ha habido una discusión relacionada sobre el rastreador de problemas de mypy (python / mypy # 3540 principalmente). Allí, percibimos que el problema principal es que los arreglos numéricos incluyen conceptualmente sus dimensiones en su tipo, y el sistema de tipos actual realmente no lo admite. Si los proyectos mypy o mecanografiado pueden ayudar de alguna manera a que la escritura funcione para numpy, ¡háganoslo saber!

Me imagino codificando más o menos información en tipos parametrizados aquí. Por ejemplo, una matriz como np.empty((2, 3)) podría ser de cualquiera de los siguientes tipos:

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

@JelleZijlstra ¿

Parece bastante claro que se requeriría un trabajo significativo en el sistema de tipos para admitir formas y dimensionalidad. Daría la bienvenida a eso (y solo escribí un montón de ideas en python / mypy # 3540), pero por ahora llamémoslo fuera del alcance de NumPy. Hacer funcionar ndarray[float64] parece bastante difícil, dada la compleja jerarquía de tipos de numpy y los desafíos de los tipos genéricos.

Sí, creo que el primer paso sería solo obtener soporte de escritura básico para numpy (y Pandas y sklearn), sin tener en cuenta las formas y otras restricciones adicionales en esos tipos.

El problema con otras restricciones adicionales es que no basta con describir un tipo d (forma = 5,6), sino que tiene que haber un lenguaje para describir una restricción en esa forma. Puede imaginar que desea definir una función que acepte solo formas cuadradas numpy como entradas, o una donde una dimensión tiene que ser 2x la otra.

Algo así se hizo en el proyecto de contratos .

También creo que sería genial apoyar el PEP 472 aquí, porque entonces se podrían hacer cosas como Array[float64, ndim=2] .

De hecho, PEP 472 sería bueno para escribir, ¡aunque probablemente sería una de las soluciones más fáciles para que esto suceda! (Por favor, escríbame si está interesado en reiniciar la discusión al respecto, ya que creo que también hay casos de uso convincentes para dimensiones con nombre en la indexación)

No estoy seguro de cómo puedo contribuir, pero definitivamente creo que sería una característica increíble por varias razones. Pero vamos en esa dirección, entonces parece que [] simplemente se convierte en una forma diferente de llamar a un objeto. Entonces object(*args, **kwargs) hace algo, object[*args, **kwargs] otra cosa, y luego podemos incluso generalizar y también tener object{*args, **kwags} y object<*args, **kwargs> . ;-)

@mitar : Mirándolo de otra manera, quizás deberíamos anotar con algo como ndarray[float].constrain(ndim=2) . Ya tenemos mucha sintaxis disponible y, a diferencia de los decoradores, las anotaciones no tienen restricciones

De hecho, probé la siguiente sintaxis: ndarray[float](ndim=2) , por lo que sobrecargar eso en genéricos __call__ devuelve nuevamente una clase y no una instancia de clase. Pero se volvió complicado para los tipos que no son genéricos.

Creo que el problema principal es con el soporte de ndarray[float] , porque ndarray[float] no es algo que realmente exista en ndarray , uno tendría que cambiar ndarray sí mismo, que No estoy seguro de que sea un buen principio general (cambiar el código ascendente para admitir una mejor escritura).

Otro enfoque podría ser tener un nuevo tipo de variables de tipo, ConstrainedTypeVar , donde podría hacer algo como ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) o algo así, y luego usaría A como var en la firma de la función. Pero esto se vuelve muy detallado.

Escribí un documento con algunas ideas sobre cómo se verían las formas de matriz de escritura con la transmisión y una noción de identidad de dimensión.

Las ideas centrales incluyen:

  1. Agregar una primitiva DimensionVar que permite identidades simbólicas para las dimensiones de la matriz
  2. Reconociendo ... ( Ellipsis ) como una transmisión de matriz indicadora.

Por ejemplo, para escribir 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]: ...

Estos serían suficientes para permitir escribir ufuncs generalizados . Consulte el documento para obtener más detalles y ejemplos.

Una posible solución para admitir dtypes y formas, si ya estamos eligiendo mantener NDArray y ndarray distintos:

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

Solo un pensamiento, ¿tendría sentido tener también un atajo como este?

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

- lo que podría simplificar una serie de firmas, especialmente en el código posterior.

@aldanor Creo que te refieres a NDArray.shape[:, :] ( ... significa "cero o más dimensiones", lo cual no es del todo correcto en este contexto). Pero sí, eso parece razonable.


Actualización rápida sobre la escritura para dtypes: escribí un módulo de juguete usando el enfoque que describí anteriormente que usa np.generic subclases con Generic para ndarray / dtype parametrizados .

Esto parece funcionar principalmente con mypy como era de esperar, incluida la inferencia de tipos con el equivalente de np.empty(..., dtype=np.float32) . No detecta uno de mis errores de tipo intencionales que involucran un tipo Union (presentaré un informe de error más adelante).

Creo que esto probablemente sería lo suficientemente bueno para dtypes. Sin el soporte de escritura para valores literales, no podríamos hacer inferencia de tipos con dtype especificado como cadenas ( dtype='float32' ). Quizás más problemático, tampoco maneja la inferencia de tipos de tipos de Python como dtype=float . Pero estos tipos pueden ser ambiguos (por ejemplo, dtype=int asigna a np.int64 en Linux y np.int32 en Windows), por lo que probablemente sea mejor usar tipos genéricos explícitos de todos modos. Está bien si la inferencia de tipos no funciona en todos los casos posibles, siempre que las especificaciones dtype=float se infieran como un dtype de Any lugar de generar un error.

Pero estos tipos pueden ser ambiguos (por ejemplo, dtype = int se asigna a np.int64 en Linux y np.int32 en Windows)

Eso no es ambiguo; en todos los casos, se asigna a np.int_ , que es el tipo C long .

Escribí la lista de correo para obtener consenso sobre cómo escribir códigos auxiliares de tipo para NumPy en un paquete separado:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

¡Increíble, gracias @shoyer !

Según el consenso en la lista de correo, me gustaría declarar https://github.com/numpy/numpy_stubs abierto para negocios.

Comenzaremos con anotaciones básicas (sin compatibilidad con dtype). Si alguien quiere armar un PR básico para agregar el andamio PEP 561 para el repositorio, ¡lo agradecería!

¡SÍ, SÍ, 1000X SÍ!

Atención a cualquiera que siga este problema: abrí dos problemas en el rastreador de python / typing:

  • ndarray escribiendo en general (https://github.com/python/typing/issues/513)
  • sintaxis para escribir ndarray (https://github.com/python/typing/issues/516)

¿Cuál es el tiempo de lanzamiento esperado para la función de escritura?
¿Hay alguna razón para intentar mantener la compatibilidad con 2.7?
Un comentario temprano mencionó la dificultad para integrarse con Python 2. Desde entonces, parece que numpy ha cambiado de postura.

Las cosas son objetivos móviles, lo sé, pero ¿tendría sentido apuntar a algo como Python 3.4-3.6?

¿Cuál es el tiempo de lanzamiento esperado para la función de escritura?

Hubo varias discusiones sobre esto (genéricos enteros también conocidos como tipos dependientes simples) en PyCon, pronto escribiré un proto-PEP basado en estas discusiones y el documento original escrito por @shoyer . Mi objetivo es conseguir que el PEP se escriba, se implemente en mypy y se acepte a tiempo para Python 3.8 beta 1 (también es muy probable que la versión posterior de los nuevos tipos en typing para Python 2)

@hmaarrfk en cuanto a escribir anotaciones de tipo para NumPy, comenzamos a hacerlo en un repositorio separado: https://github.com/numpy/numpy-stubs. Debería poder instalar y usar esos stubs en el estado actual (con la última versión de mypy), pero están lejos de estar completos. ¡Agradeceríamos su ayuda!

Claro, me alegra ayudar en lo que puedo y vi el repositorio. Solo sé que estas cosas llevan tiempo.
Vi el repositorio y noté que una confirmación mencionaba la compatibilidad con 2.7, por lo que pregunté.

El lanzamiento de la versión beta de Python 3.8 es a mediados de 2019 . Numpy mencionó que detendrían las nuevas funciones a fines de 2018 .

Escribir parece ser una característica "agradable de tener" para numpy en lugar de una "imprescindible". Como tal, apuntar a dos idiomas parece un poco difícil, especialmente, si la función comenzará a aparecer mucho más allá de la fecha límite de soporte de numpy.

Me interesaría leer lo que @ilevkivskyi tiene que decir en el PEP.

@hmaarrfk Plantea un buen punto sobre la compatibilidad con Python 2.7. Para ser honesto, todavía no lo he pensado completamente. Espero que eventualmente lo dejemos, pero probablemente no antes de que mypy deje de admitir Python 2.7, dado que un caso de uso importante para escribir es escribir código compatible con Python 2/3.

Por ahora, no parece requerir muchos compromisos para admitir Python 2 en nuestras anotaciones de tipo, así que estoy feliz de dejarlo, especialmente dado que provino de un colaborador que evidentemente estaba interesado en él.

Quería tocar esto nuevamente para ver si las discusiones han progresado, especialmente con respecto a la información de forma de sugerencia de tipo, que sería particularmente útil en muchas de mis aplicaciones. ¿Existe un rastreador de estado o no es una prioridad lo suficientemente alta como para tener recursos dedicados a él?

En transonic , un proyecto para generalizar numerosos aceleradores, tenemos una sintaxis de sugerencia de tipo como alternativa para las anotaciones Pythran que usa comentarios . No funciona bien con mypy en este momento, pero me pregunto si es útil. Vea un ejemplo: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

En caso de que sea útil para este problema, mencionaré que he creado una herramienta para convertir cadenas de documentos para escribir comentarios: https://pypi.org/project/doc484/

Utilizo esto con el compromiso previo en varios proyectos para mantener las cadenas de documentos sincronizadas con los comentarios de tipo.

Aún necesitará convertir los tipos en sus cadenas de documentos para que sean compatibles con PEP484.

Hola a todos,

Quería hacer mi parte, así que bifurqué el repositorio y comencé a agregar sugerencias de tipo. Mi idea era trabajar de abajo hacia arriba, así que comience con las funciones "simples" y trabaje hacia arriba desde allí. (Comenzando con las frutas bajas)

Por ejemplo, en _string_helpers.py , agregué sugerencias de tipo a algunas variables y funciones.

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

¿Qué piensas sobre esto?

Recomendaría hacer un poco y abrir un PR para recibir comentarios. numpy está apuntando a pitones más antiguos (3.5 anotaciones introducidas, IIRC) y esto rompería esas compilaciones, así que tal vez busque escribir archivos .pyi o consulte los documentos mypy para ver si hay un poco más de orientación sobre las mejores prácticas.

Hemos estado haciendo anotaciones hasta ahora en los numpy-stubs separados
repositorio, pero ha sido un proceso lento.

El jueves 14 de noviembre de 2019 a las 9:57 a.m., Ben Samuel [email protected] escribió:

Recomendaría hacer un poco y abrir un PR para recibir comentarios. numpy
apunta a pitones más antiguos (3.5 anotaciones introducidas, IIRC) y este
rompería esas compilaciones, así que quizás considere escribir archivos .pyi o verifique
mypy docs para ver si hay un poco más de orientación sobre las mejores prácticas.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFVREXWG43WWMVAQMDFVREXWG43WZMV
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

@ bsamuel-ui numpy actualmente requiere Python 3.5+, y NEP-29 [1] indica que debería estar bien subirlo a 3.6+
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

Las anotaciones (para argumentos de función y tipos de retorno) son compatibles con todas las versiones de Python 3; 3.6 solo introdujo anotaciones de variables. En la primera versión de Python 3 (<3.5), debe usar un backport del módulo typing .

Agregué una solicitud de extracción con mi primer archivo .pyi. Necesita un poco de trabajo, pero sería bueno si ustedes pudieran echarle un vistazo para que pueda obtener algunos comentarios iniciales.

Como se menciona en gh-14905, tenemos los inicios de una biblioteca de stub en https://github.com/numpy/numpy-stubs. Sería genial hacerlo con las pruebas adecuadas y luego podríamos decidir la mejor manera de empaquetarlo o fusionarlo en numpy / numpy propiamente dicho.

Mi mal @mattip. Eliminaré la solicitud de extracción de numpy y agregaré una nueva a numpy-stubs

todavía está abierto, pero creo que numpy ya lo admite en la versión maestra

Hola,
Estoy tratando de definir un alias de tipo para el vector 3d, por lo que una gran variedad de formas (3,) de dtype int32.

(Sé que puedo escribir sugerencia con np.ndarray, pero ¿cómo puedo ser más específico? Leí todo aquí y no lo entendí, también busqué un tutorial sobre cómo usar tipos numpy para escribir en Python pero no lo hice encontrar cualquier cosa. )

Como si fuera posible escribir:

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

Intenté hacer:

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

¿Es la forma correcta de hacerlo?

¿Puede alguien aquí señalarme un tutorial o un ejemplo, por favor?

Además, encontré este repositorio que es "Escriba sugerencias para Numpy": https://github.com/ramonhagenaars/nptyping

¿Numpy integrará esto?
@ramonhagenaars

@mattip

Como se menciona en gh-14905, tenemos los inicios de una biblioteca de stub en https://github.com/numpy/numpy-stubs.

Parece que esto se ha fusionado en el repositorio principal. ¿Se ha publicado esto o está en la hoja de ruta? Tratando de decidir si deberíamos explorar algo de terceros como https://github.com/ramonhagenaars/nptyping o (idealmente) esperar / usar sugerencias de tipo admitidas oficialmente.

Gracias.

Hemos fusionado gran parte de los códigos auxiliares numéricos en la rama de desarrollo. Puede seguir el progreso buscando la etiqueta de escritura estática . Con suerte, esto será parte del próximo lanzamiento. Puede probar lo que está combinado actualmente usando una versión HEAD de numpy. Siempre estamos buscando colaboradores: revisión constructiva, documentación y comentarios sobre los problemas y solicitudes de extracción son algunas formas de ayudar.

(Sé que puedo escribir sugerencia con np.ndarray, pero ¿cómo puedo ser más específico? Leí todo aquí y no lo entendí, también busqué un tutorial sobre cómo usar tipos numpy para escribir en Python pero no lo hice encontrar cualquier cosa. )

Hay mucho interés en esta área, pero aún no se admiten tipos más específicos (dtypes y dimensiones) para matrices NumPy.

@ GilShoshan94 FWIW He presentado https://github.com/ramonhagenaars/nptyping/issues/27

¿Fue útil esta página
0 / 5 - 0 calificaciones