Numpy: Solicitud: use el control de versiones semántico

¿Se podría considerar que numpy está usando versiones semánticas, pero con un 1 principio?

Tenga en cuenta que casi todos los proyectos científicos centrales de Python hacen lo que hace NumPy: eliminar el código obsoleto después de un par de lanzamientos, a menos que sea muy perturbador, y solo aumente el número de versión principal para, bueno, cosas importantes.

No estoy seguro de si está proponiendo un cambio en la política de obsolescencia o si cree que deberíamos tener la versión 14.0.0 en lugar de la 1.14.09 ahora.

Lo último: NumPy debería estar aproximadamente en la versión 14 a estas alturas. Pero propongo adoptar esta convención solo para versiones futuras.

Por cierto: el predecesor de NumPy, Numeric, usó versiones semánticas y llegó a la versión 24 durante aproximadamente una década. No sé por qué se cambió esto en la transición a NumPy.

Mi impresión es que la gran mayoría de los proyectos de Python no utilizan versiones semánticas. Por ejemplo, Python en sí no utiliza versiones semánticas. (Tampoco conozco ningún sistema operativo o compilador convencional que utilice semver, ¿tiene alguno en mente?). Estoy de acuerdo en que los proponentes de semver han hecho un gran trabajo comercializándolo, lo que ha llevado a muchos desarrolladores a pensar que es un buen idea, pero AFAICT es esencialmente impracticable en el mundo real para cualquier proyecto más grande que el panel izquierdo, y disputo firmemente la idea de que la gente de semver ahora "posee" el formato tradicional MAJOR.MINOR.MICRO y todos los demás tienen que cambiar a algo más.

¿Puede dar un ejemplo de lo que quiere decir con un "esquema de etiquetado de versiones que no puede confundirse con versiones semánticas"? ¿Usar nombres en lugar de números? Citas el control de versiones basado en fechas, pero el esquema más común para esto que he visto es el que usan, por ejemplo, Twisted y PyOpenSSL, que actualmente están en 17.9.0 y 17.5.0, respectivamente. Esas me parecen versiones semver totalmente plausibles ...

¿Y puede explicar qué beneficio tendría esto para los usuarios? En este futuro hipotético, cada lanzamiento tendría algunos cambios importantes que son irrelevantes para la mayoría de los usuarios, como ahora. ¿Qué información útil estaríamos transmitiendo al aumentar el número mayor cada pocos meses? "Esto probablemente rompe a alguien, pero probablemente no te rompe a ti"? ¿Deberíamos incluir también la versión principal en las versiones de corrección de errores, dada la inevitabilidad histórica de que una gran proporción de ellas romperá al menos el código de una persona? ¿Puede dar algún ejemplo de "desarrolladores de software, usuarios de software y administradores de distribuciones de software" que realmente se hayan confundido?

Tenga en cuenta que la lista de correo es un lugar más apropiado para esta discusión, y probablemente tendríamos que tener una discusión allí antes de realizar cualquier cambio, pero los comentarios aquí deberían ser útiles para tener una idea de qué tipo de problemas desea para abordar en esa discusión.

@njsmith Parece que el único punto fáctico en el que no estamos de acuerdo es si el control de versiones semántico es la suposición predeterminada actual. Esto requiere una definición más clara de la comunidad en la que es (o no) la predeterminada. Los niveles de administración de software que me preocupan son la administración de distribución y la administración de sistemas, que es donde la gente decide qué versión es la más apropiada en su contexto.

La investigación informal que me llevó a la conclusión de que el control de versiones semántico es el predeterminado consistió en hablar con administradores de instalaciones de computación científica. Yo también imaginé
un enfoque más empírico (enumerar los paquetes en una instalación reciente de Debian y seleccionar algunos de ellos al azar para investigar su enfoque de control de versiones), pero esto resultó ser muy difícil, porque pocos proyectos establecen claramente si usan control de versiones semántico o no.

Un comentario de un administrador de sistemas me pareció particularmente relevante: dijo que a los efectos de decidir qué versión instalar, cualquier convención que no sea el control de versiones semántico es inútil. Los administradores de sistemas no pueden explorar cada paquete en detalle (carecen de tiempo y competencia) ni consultar a todos sus usuarios (demasiados). Tienen que adoptar una política uniforme, y esto tiende a basarse en el supuesto de versionado semántico. Por ejemplo, un administrador de un clúster informático me dijo que consulta con algunos "usuarios avanzados" que conoce personalmente antes de aplicar una actualización con un cambio en el número de versión principal.

En cuanto a ejemplos de personas que realmente han estado confundidas, específicamente en lo que respecta a los usuarios científicos de Python, tengo muchos: colegas en el trabajo, personas que conozco en conferencias, personas que piden consejos por correo electrónico, estudiantes en mis clases. Esto suele comenzar con "Sé que eres un experto en Python, ¿puedes ayudarme con un problema?" Ese problema resulta ser un script que funciona en una computadora pero no en otra. La mayoría de estas personas no consideran en absoluto los problemas de dependencia, pero algunos sí compararon los números de versión de las dos instalaciones, encontrando sólo "pequeñas diferencias".

Como señalaron @ eric-wieser y @rgommers , mi solicitud es casi sinónimo de solicitar que el "1" inicial ser eliminado de las versiones de NumPy. En otras palabras, NumPy de facto ya usa versiones semánticas, aunque no es el resultado de una decisión de política y, por lo tanto, probablemente no se haga de manera rigurosa. Sin embargo, sí sugiere que NumPy podría adoptar versiones semánticas casi sin cambios en el flujo de trabajo de desarrollo actual.

Un comentario de un administrador de sistemas me pareció particularmente relevante: dijo que a los efectos de decidir qué versión instalar, cualquier convención que no sea el control de versiones semántico es inútil.

Desafortunadamente, las versiones semánticas también son inútiles para esto :-(. No me refiero a dividir los pelos o exagerar; entiendo totalmente que es un problema real. Pero solo porque un problema sea real no significa que tenga una solución. Básicamente, no se puede reducir la pregunta "¿debo actualizar este software?" lanzamientos.

Los administradores de sistemas no pueden explorar cada paquete en detalle (carecen de tiempo y competencia) ni consultar a todos sus usuarios (demasiados). Tienen que adoptar una política uniforme, y esto tiende a basarse en el supuesto de versionado semántico. Por ejemplo, un administrador de un clúster informático me dijo que consulta con algunos "usuarios avanzados" que conoce personalmente antes de aplicar una actualización con un cambio en el número de versión principal.

Aunque me gusta esta parte :-). Dudo que estemos de acuerdo con la filosofía de semver, pero es mucho más fácil tener una discusión sobre los efectos concretos de los diferentes esquemas de versiones y qué resultado encontramos más deseable.

No creo que el concepto de semver tenga mucho que ver con esta política: ¿el administrador del sistema con el que habló realmente verifica cada proyecto para ver si están usando semver? La mayoría de los proyectos no lo hacen, como dijiste, es difícil saber cuáles lo hacen. Y la política es la misma que los administradores de sistemas han estado usando desde mucho antes de que existiera semver. Creo que una mejor caracterización de esta política sería: "siga la recomendación del proyecto sobre el cuidado que debe tener con una actualización", junto con la antigua tradición de que las versiones principales son "grandes" y las versiones menores son "pequeñas".

La recomendación del proyecto NumPy es que los administradores del sistema deben actualizar a nuevas versiones de funciones, por lo que lo que saco de esta anécdota es que nuestro esquema de numeración actual comunica con precisión lo que queremos, y que cambiar a semver no ...

@njsmith De acuerdo,

Nuevamente, parece que aquí tenemos una gran diferencia de opinión. Para usted, son los desarrolladores quienes dan instrucciones a los encargados del mantenimiento del sistema y a los usuarios, y utilizan los números de versión para transmitir sus instrucciones. Para mí, cada jugador debería decidir según su criterio, y el número de versión debería actuar como un medio de comunicación fáctica al nivel más burdo.

Dado que NumPy no tiene implicaciones de seguridad, no veo cómo y por qué el proyecto NumPy debería dar recomendaciones universales. Las personas y las instituciones tienen necesidades diferentes. Es por eso que tenemos ArchLinux y CentOS, con políticas de actualización muy diferentes.

@khinsen El oldnumeric todavía funciona perfectamente y la gente puede instalarlo con:

pip install oldnumeric

Quizás este podría ser su "numpy estable" propuesto, donde la interfaz de numpy está restringida a Python / Cython y nunca se cambia nada. Por supuesto, escribir código con oldnumeric es muy arcano, pero no puede tener las dos cosas.

@xoviat Es cierto, pero ese es un tema diferente. Mi punto aquí no es la preservación del software, sino la comunicación entre los diferentes actores en la gestión del software.

Pregunta: Como administrador de sistemas (incluso solo en su máquina personal), ¿esperaría que un paquete elimine una capa API completa de la versión 1.8 a la versión 1.9?

Para aquellos que respondieron "sí", segunda pregunta: ¿pueden nombrar algún software que no sea Numpy que haya hecho esto alguna vez?

Por cierto, les puedo asegurar que muchas personas fueron mordidas por esto, porque recibí muchos correos preguntándome por qué MMTK dejó de funcionar de un día para otro. Todas estas personas habían realizado actualizaciones de rutina de sus instalaciones de software, sin esperar consecuencias graves.

Pero dejar caer oldnumeric no fue el peor evento en la historia reciente de NumPy. Ese honor es para cambiar la semántica de copia / vista de algunas operaciones como diagonal . El código que devuelve resultados diferentes según la versión de NumPy (¡cambio de número de versión menor!) Es una verdadera pesadilla.

Por cierto, ya que casi nadie conoce la historia: pip install oldnumeric funciona desde hace dos días, porque @xoviat preparó este paquete de complementos y lo puso en PyPI. ¡Muchas gracias!

¿esperaría que un paquete elimine una capa API completa de la versión 1.8 a la versión 1.9?

¿A qué capa te refieres?

¿Puede nombrar algún software que no sea numpy que haya hecho esto?

SciPy eliminó los paquetes weave y maxentropy , pandas rompe las características principales con regularidad. Estoy seguro de que hay muchos ejemplos más destacados. EDITAR: Python en sí, por ejemplo, consulte https://docs.python.org/3/whatsnew/3.6.html#removed

Por cierto, les puedo asegurar que muchas personas fueron mordidas por esto, porque recibí muchos correos preguntándome por qué MMTK dejó de funcionar de un día para otro. Todas estas personas habían realizado actualizaciones de rutina de sus instalaciones de software, sin esperar consecuencias graves.

Ese cambio tardó unos 10 años en realizarse, y no hay forma de que un esquema de control de versiones diferente hubiera hecho una diferencia aquí.

Eliminar las funciones obsoletas es una compensación entre romper una pequeña fracción del código (más antiguo) y mantener la base de código fácil de mantener. En general, si nos equivocamos, es probable que lo hagamos por el lado conservador. Como alguien que también ha tenido que lidiar con grandes bases de códigos corporativos de muchos años que usan numpy, siento su dolor, pero está defendiendo algo que no es en absoluto una solución (y en general no hay una solución completa; educar a los usuarios sobre cosas como fijar versiones y comprobar si hay advertencias de obsolescencia es lo mejor que podemos hacer).

¿A qué capa te refieres?

soporte numérico / numarray, supongo

@rgommers Lo siento, debería haber dicho "otro ejemplo fuera del ecosistema SciPy".

Además, no me quejo por dejar de lado el soporte para oldnumeric . Me quejo de hacer esto sin cambiar el número de versión principal.

¿Qué diferencia habría hecho eso? Habría hecho que la gente dudara en actualizar sin leer las notas de la versión. Todos los que usen (pero no desarrollen) código Python habrían tomado esto como una señal de tener cuidado.

No olvide que el ecosistema SciPy tiene una enorme cantidad de usuarios de bajo perfil que no están siguiendo activamente los desarrollos. Python y NumPy son elementos de infraestructura de la misma naturaleza que ls y gcc para ellos. Y a menudo es menos que eso: usan algún software que está escrito en Python y depende de NumPy, y cuando se rompe, se pierden por completo.

@rgommers Lo siento, debería haber dicho "otro ejemplo fuera del ecosistema SciPy".

Acabo de editar mi respuesta con un enlace a las notas de la versión de Python, eso está fuera del ecosistema SciPy.

¿Qué diferencia habría hecho eso? Habría hecho que la gente dudara en actualizar sin leer las notas de la versión. Todos los que usen (pero no desarrollen) código Python habrían tomado esto como una señal de tener cuidado.

Este simplemente no será el caso. Si en lugar de 1.12, 1.13, 1.14, etc. tenemos 12.0, 13.0, 14.0, los usuarios se acostumbrarán a eso y usarán la misma estrategia de actualización que antes. La gran mayoría no se volverá de repente mucho más conservadora.

No olvide que el ecosistema SciPy tiene una enorme cantidad de usuarios de bajo perfil que no están siguiendo activamente los desarrollos. Python y NumPy son elementos de infraestructura de la misma naturaleza que ls y gcc para ellos. Y a menudo es menos que eso: usan algún software que está escrito en Python y depende de NumPy, y cuando se rompe, se pierden por completo.

Todo es cierto y no todo se puede arreglar mágicamente con un número de versión. Si ejecutaron pip install --upgrade numpy , deben saber lo que están haciendo (y de todos modos esto ni siquiera muestra un número de versión). Si es su sistema de empaquetado, entonces están viendo el problema de que el software se rompe al no tener un conjunto de pruebas decente (o que no se ejecutó).

Otras desventajas de cambiar el esquema de control de versiones ahora:

• haríamos un cambio en las versiones sin un cambio en las políticas de mantenimiento, sería más confuso que útil
• ahora básicamente estamos siguiendo el ejemplo de Python y haciendo lo mismo que el resto de todo el ecosistema. Esa es una buena cosa
• quizás lo más importante: perderíamos la capacidad de señalar cambios realmente importantes. el tipo para el que iríamos a 2.x, como un lanzamiento que rompería el ABI.

Mi referencia básica no es Python, sino una instalación de software típica. Como dije, para muchos (quizás la mayoría) de los usuarios, NumPy es una infraestructura como gnu-coreutils o gcc. No interpretan los números de versión específicamente en el contexto del ecosistema SciPy.

Hice una comprobación rápida en un sistema Debian 9 con unos 300 paquetes instalados. El 85% de ellos tiene un número de versión que comienza con un número entero seguido de un punto. Los prefijos enteros más comunes son 1 (30%), 2 (26%), 0 (14%) y 3 (13%). Si NumPy adoptara un esquema de numeración de versiones que se ajustara a las expectativas comunes (es decir, versiones semánticas o una aproximación cercana), definitivamente se destacaría y se trataría con precaución.

Tenga en cuenta también que las únicas actualizaciones en el software instalado por Debian que alguna vez rompieron las cosas para mí fueron en el ecosistema SciPy, con la única excepción de una actualización de Emacs que trajo cambios en el modo org que rompió una extensión del modo org hecho en casa. Los prefijos de números de versión bajos en general parecen indicar que el software más utilizado es mucho más estable que NumPy y sus amigos.

La uniformidad en todo el ecosistema SciPy es realmente importante, pero preferiría que todo el ecosistema adopte un esquema de versiones que se ajuste a las expectativas del mundo exterior. Simplemente estoy comenzando con NumPy porque lo veo como la parte más básica. Es incluso más infraestructura que cualquier otra cosa.

Finalmente, considero que un cambio en la semántica de una función es un cambio mucho más importante que un cambio en el ABI. Lo primero puede causar pesadillas de depuración para cientos de usuarios y hacer que los programas produzcan resultados erróneos no detectados durante años. Esto último genera mensajes de error que indican claramente la necesidad de arreglar algo.

De acuerdo con esos estándares, NumPy ni siquiera está siguiendo el ejemplo de Python, porque los únicos cambios en la semántica que conozco en el lenguaje Python ocurrieron de 2 a 3.

Finalmente, considero que un cambio en la semántica de una función es un cambio mucho más importante que un cambio en el ABI. Lo primero puede causar pesadillas de depuración para cientos de usuarios y hacer que los programas produzcan resultados erróneos no detectados durante años. Esto último genera mensajes de error que indican claramente la necesidad de arreglar algo.

Nos esforzamos mucho en no hacer esto. Puede ocurrir una rotura clara cuando se elimina alguna característica, pero los resultados numéricos cambiantes silenciosamente no deberían. Eso es algo que aprendimos del cambio de vista diagonal: fue un error en retrospectiva.

definitivamente se destacaría y sería tratado con precaución.

Sigo en desacuerdo. Incluso en Debian, que definitivamente no es "una instalación de software típica" para nuestra base de usuarios (eso sería algo como Anaconda en Windows). También parece que ignora mi argumento anterior de que un usuario ni siquiera puede ver un número de versión normalmente (ni con pip install --upgrade ni con un administrador de paquetes).

Además, su experiencia de que todo lo demás nunca se rompe es probable porque está usando cosas como utilidades del sistema operativo y programas GUI, no otras grandes cadenas de dependencia. Por ejemplo, todo el ecosistema de JavaScript / NodeJS es probablemente más frágil que el de Python.

Por cierto, puedo asegurarles que muchas personas fueron mordidas por esto, porque recibí muchos correos que me preguntaban por qué MMTK dejó de funcionar de un día para otro

Este es un buen ejemplo de las sutilezas aquí. Hasta donde yo sé, MMTK y sus otros proyectos son los únicos que aún existen y se vieron afectados por la eliminación del código de compatibilidad numérico / numarray. ¿Cuántos usuarios estima que tiene? 100? 1000? NumPy tiene millones, así que tal vez el 0.1% de nuestros usuarios se vieron afectados por esta eliminación. Definitivamente, esto no es cero, y el hecho de que sea pequeño no significa que no importe. Ojalá pudiéramos apoyar al 100% de los usuarios para siempre en todos los sentidos. Y entiendo que es particularmente doloroso para ti recibir el 100% de las quejas de tus usuarios.

Pero si aumentamos nuestro número de versión principal para esto, significa que para el 99,9% de nuestros usuarios, acabamos de gritar lobo. Es un falso positivo. OTOH para ese 0,1% de usuarios, fue realmente importante. Sin embargo, no es raro que rompamos a más del 0.1% de los usuarios en micro- lanzamientos, a pesar de nuestros mejores esfuerzos. ¿Asi que que hacemos?

Simplemente no es posible comunicar estos matices a través del instrumento contundente de un número de versión. Todos quieren una forma rápida de saber si una actualización romperá su código, por buenas razones. Semver es popular porque promete hacer eso. Es popular por la misma razón por la que es popular pensar que las dietas de moda pueden curar el cáncer. Ojalá semver también estuviera a la altura de sus promesas. Pero no es así, y si queremos ser buenos ingenieros tenemos que lidiar con las complejidades de esa realidad.

No veo cómo y por qué el proyecto NumPy debería dar recomendaciones universales. Las personas y las instituciones tienen necesidades diferentes.

Damos recomendaciones universales porque solo tenemos 1 número de versión, por lo que, por definición, todo lo que hagamos con él es una recomendación universal. Eso no es algo sobre lo que tengamos ningún control.

Ese honor es para cambiar la semántica de copia / vista de algunas operaciones como diagonal .

IIRC, literalmente, no hemos recibido una sola queja sobre esto de alguien que diga que rompió su código. (¿Quizás una persona?) No estoy diciendo que eso signifique que nadie se vio afectado, obviamente, las personas que se quejan de un cambio son, en general, solo una pequeña fracción de los afectados, pero si usa las quejas como una aproximación aproximada de lo real, impacto mundial, entonces no creo que esto esté entre los 50 primeros.

Y por cierto, estoy bastante seguro de que si buscas en el historial profundo, puedes encontrar cambios mucho más atroces que ese :-).

Tenga en cuenta también que las únicas actualizaciones en el software instalado por Debian que alguna vez rompieron las cosas para mí fueron en el ecosistema SciPy, con la única excepción de una actualización de Emacs que trajo cambios en el modo org que rompió una extensión del modo org hecho en casa.

Respetuosamente, creo que esto dice más sobre cómo se usa NumPy vs Debian que sobre NumPy vs Debian. Amo Debian, lo he usado durante casi 20 años y no puedo contar cuántas veces tiene cosas rotas. Solo en la última semana, un problema extraño con el nuevo gnomo rompió mis scripts de inicio de sesión y alguna otra actualización rompió mi trackpoint . (Ambos están arreglados ahora, pero aún así). También señalaré que emacs de Debian se configuró para descargar y ejecutar código en canales no cifrados / inseguros durante años, debido a preocupaciones de compatibilidad con versiones anteriores sobre la habilitación de controles de seguridad. No creo que exista una versión de gcc que no rompa a algunas personas, aunque solo sea porque la gente hace cosas como usar -Werror y luego cambios menores en el comportamiento de advertencia (que puede depender de sutiles interacciones entre pases de optimización, etc.) se convierten en cambios importantes.

Los prefijos de números de versión bajos en general parecen indicar que el software más utilizado es mucho más estable que NumPy y sus amigos.

Los prefijos generales de números de versión bajos se deben a que la mayoría de los programas de software utilizados no utilizan semver.

Finalmente, considero que un cambio en la semántica de una función es un cambio mucho más importante que un cambio en el ABI. Lo primero puede causar pesadillas de depuración para cientos de usuarios y hacer que los programas produzcan resultados erróneos no detectados durante años. Esto último genera mensajes de error que indican claramente la necesidad de arreglar algo.

Sí, es por eso que estamos extremadamente cuidadoso de tales cambios.

Hay algo de desconexión en las perspectivas aquí: parece que piensas que cambiamos las cosas de cualquier manera todo el tiempo, no nos importa la compatibilidad con versiones anteriores, etc. Puedo respetar eso; Entiendo que refleja tu experiencia. Pero nuestra experiencia es que ponemos extremo cuidado en tales cambios, y yo diría que cuando hablo con los usuarios, es ~ 5% quien tiene su perspectiva y ~ 95% que siente que numpy está haciendo un buen trabajo en estabilidad, o que está haciendo un trabajo demasiado bueno y debería estar más dispuesto a romper cosas. Quizás pueda consolarse sabiendo que incluso si lo decepcionamos, también decepcionaremos al último grupo :-).

con la única excepción de una actualización de Emacs

Bueno, para salirse del tema, eso sirve como un ejemplo del otro lado de la estabilidad. Emacs estuvo estático durante años debido a la resistencia de Stallman al cambio, y eso resultó en la bifurcación xEmacs. Mi propio camino fue Emacs -> xEmacs, diablos, -> Vim;) La fosilización prematura es también la razón por la que dejé de usar Debian en su día. Para algunas cosas, el cambio simplemente no es necesario o ni siquiera deseado, y espero que haya personas que ejecuten versiones antiguas de BSD en hardware antiguo escondido en un armario. Pero no espero que haya muchos lugares así.

A propósito del problema actual, no creo que un cambio en el esquema de control de versiones realmente haga alguna diferencia. Un camino más productivo podría ser abordar el problema de la modernización. @khinsen ¿Ve la forma de aceptar la actualización de sus principales proyectos? Si es así, creo que deberíamos explorar formas en las que podamos ayudarlo a hacerlo.

Estoy intentando actualizar los proyectos en
https://github.com/ScientificPython. Requiere actualizar el código Python que
utilizó la antigua API C (y me refiero a la antigua; algunas funciones como Py_PROTO fueron
desde 2000). Por supuesto, los RP son bienvenidos, pero no estoy seguro de si alguien
quiere dedicar su tiempo a eso.

El problema más importante que creo que mencionó es que hay "muchos
proyectos "(no sé dónde están exactamente porque todos los proyectos
que he visto soporte para Python 3) que también necesita actualización; Cómo es
determinado a qué proyectos se les asigna tiempo de desarrollo NumPy? Y tambien yo
No creo que su afirmación central fuera inválida: SciPy se beneficia enormemente de la
hecho de que podría simplemente copiar y pegar viejos proyectos de Fortran (como
fftpack) con poca o ninguna modificación. Si estos hubieran sido escritos en decir
"fortran 2" y los nuevos compiladores solo compilaron "fortan 3", habría
Han sido problemas importantes.

Dicho esto, estos problemas no son realmente culpa de NumPy. A pesar de lo que tiene
dijo, con NumPy 1.13 instalado, oldnumeric todavía pasó todas las pruebas,
lo que indica que NumPy no es el culpable aquí. Dado que la API numérica antigua es
literalmente tiene más de una década (¡tal vez acercándose a dos décadas!), y todavía
funciona en el último NumPy, creo que la API de NumPy probablemente sea estable
suficiente.

@charris Estoy totalmente de acuerdo contigo en que "nunca cambiar nada" no es una actitud productiva en la informática.

Mi punto es que el ecosistema SciPy se ha vuelto tan inmensamente popular que ningún enfoque único para gestionar el cambio puede adaptarse a todos. Depende de la rapidez con la que evolucionen los métodos y sus implementaciones en un campo determinado, de las competencias técnicas de los profesionales, de otro software del que dependan, de los recursos que puedan invertir en código, etc.

El equipo central actual de NumPy se preocupa más por el progreso (en una dirección que es importante para algunos campos pero que es en gran medida irrelevante para otros) que por la estabilidad. Eso está bien: en el mundo del código abierto, las personas que hacen el trabajo deciden en qué quieren trabajar. Sin embargo, mi impresión es que no se dan cuenta de que muchas personas cuyo trabajo depende de NumPy tienen necesidades diferentes, se sienten abandonadas por el equipo de desarrollo y están comenzando a alejarse de SciPy hacia tecnologías más tradicionales y estables como C y Fortran ( y, en un caso lo sé, incluso a Matlab).

No tengo idea de qué porcentaje de usuarios de NumPy están suficientemente descontentos con la situación actual, y no creo que nadie más lo haya hecho. Una vez que un paquete de software se convierte en infraestructura, no es fácil estimar quién depende de él. Muchos de los que lo saben ni siquiera lo saben, y gran parte del código que depende de NumPy (directa o indirectamente) no es público y / o no se puede descubrir fácilmente.

Si queremos que todos los miembros de la comunidad SciPy estén contentos, debemos encontrar la manera de abordar las diversas necesidades. El primer paso, en mi opinión, es cambiar el control sobre la tasa de cambio en una instalación específica de los desarrolladores a alguien que esté más cerca del usuario final. Podrían ser los propios usuarios finales, los administradores de sistemas, los empaquetadores o cualquier otra persona; de nuevo, no creo que haya una respuesta universal a esta pregunta. Lo que esto requiere de los desarrolladores es información al nivel correcto, y es por eso que comencé este hilo. Por supuesto, los números de versión no pueden salvar el mundo, pero los veo como un primer paso para establecer una responsabilidad distribuida para la gestión del cambio.

Finalmente, algunos de ustedes parecen creer que estoy librando una batalla personal sobre mi propio código. Puede que les sorprenda que mi actitud personal no sea la que defiendo aquí. Mi propio punto dulce para la tasa de cambio se encuentra en algún lugar entre lo que es común en mi campo y lo que parece prevalecer en el equipo de NumPy. La mayor parte de mi trabajo actual usa Python 3 y NumPy> 1.10. MMTK tiene 20 años y hoy hago muchas cosas de manera diferente. Muy a menudo tomo fragmentos de código de MMTK que necesito para un proyecto específico y los adapto a "SciPy moderno", pero eso es algo que puedo hacer con confianza solo porque escribí el código original.

He estado manteniendo un MMTK estable como un servicio a la comunidad, no para mi propio uso, lo que explica por qué he estado haciendo mantenimiento de manera minimalista, evitando cambios a gran escala en la base de código. Tanto la financiación para el software como para los desarrolladores competentes en el dominio son muy difíciles de encontrar, por lo que MMTK siempre ha sido un proyecto de un mantenedor más contribuidores ocasionales. Ni siquiera estoy seguro de que trasladar todo MMTK a "SciPy moderno" sea beneficioso para alguien, porque gran parte del código que depende de MMTK no se mantiene completamente. Pero eso es cierto para la mayor parte del código Python que veo a mi alrededor, incluso el código completamente ajeno a MMTK. Es la realidad de un campo de investigación donde los experimentos en lugar de la computación y la codificación son el foco de atención.

@xoviat El número de pruebas en oldnumeric es ridículamente pequeño. No sacaría mucha conclusión del hecho de que pasan con NumPy 1.13.

Los módulos de extensión de C que ha estado viendo tienen literalmente 20 años y fueron escritos para Python 1.4. En aquel entonces, se encontraba entre los ejemplos más sofisticados de combinaciones de Python-C y de hecho dio forma al desarrollo temprano de Numeric (pre-NumPy) e incluso del propio CPython: los CObjects (pre-Capsules) se introdujeron en función de las necesidades de ScientificPython y MMTK. .

Soy el primero en decir que las API y las herramientas de soporte de hoy son mucho mejores y espero que sigan mejorando en el futuro. Pero algunas personas simplemente quieren usar software para investigar, sin importar cuán anticuado sea, y creo que también tienen derecho a existir.

@rgommers No estoy ignorando su argumento de que un usuario ni siquiera puede ver un número de versión. Simplemente no es cierto para los entornos que veo que la gente usa a mi alrededor. Las personas que deciden sobre las actualizaciones (que no siempre son usuarios finales) sí lo ven. No solo hacen "instalación de pip - actualización" una vez a la semana. Incluso considerarían esto como una actitud descuidada.

Si la gente de nuestro entorno utiliza principalmente Anaconda en Windows, eso solo confirma que trabajamos en entornos muy diferentes. En la era de la diversidad, espero que podamos estar de acuerdo en que cada comunidad puede adoptar las herramientas y convenciones que funcionan bien para ella.

Y sí, NodeJS es peor, estoy de acuerdo. Afortunadamente, puedo ignorarlo fácilmente.

Acabo de recibir un correo electrónico de un colega que sigue este hilo pero que no se atrevería a intervenir. Con una excelente analogía:

"Me encanta cuando tengo la oportunidad de comprar un microscopio nuevo y hacer mejor ciencia con él. Pero odiaría ver a alguien reemplazando mi microscopio de la noche a la mañana sin consultarme".

Se trata de tener control sobre las propias herramientas.

Prometo que nunca irrumpiré en el laboratorio de su colega en medio de la noche y actualizaré su numpy. Ni siquiera tengo un pasamontañas .

Las personas que deciden sobre las actualizaciones (que no siempre son usuarios finales) sí lo ven. No solo hacen "instalación de pip - actualización" una vez a la semana. Incluso considerarían esto como una actitud descuidada.

Si son administradores de sistemas y comprenden los pros y los contras de varios métodos de instalación, entonces también deberían comprender (o aprender) cómo funciona el control de versiones en el mundo Python (y muchos otros proyectos de software que tampoco utilizan semver estricto).

El equipo central actual de NumPy se preocupa más por el progreso (en una dirección que es importante para algunos campos pero que es en gran medida irrelevante para otros) que por la estabilidad.

Lo siento, pero esto solo muestra que no has estado siguiendo el desarrollo de NumPy en los últimos años, o tienes un par de anteojos muy particular. NumPy es en realidad un proyecto muy difícil al que contribuir, porque hay mucha preocupación por la compatibilidad con versiones anteriores. Esa es una de las principales razones por las que nos cuesta atraer nuevos mantenedores.

y, en un caso lo sé, hasta Matlab

Matlab era conocido por romper la compatibilidad. Lo primero que hicieron los proyectos cooperativos que usaban Matlab fue especificar la versión que todos debían usar, lo mismo con Microsoft Word si se estaba usando para documentación. Conozco a gente que se cambió a NumPy precisamente para mejorar la compatibilidad. Matlab tiene sus virtudes, pero la compatibilidad no es / no era una de ellas. ¿Quizás las cosas hayan cambiado?

Sin embargo, creo que hay un par de cosas que podemos hacer en el futuro que podrían ayudar con la compatibilidad. El primero se relaciona con el debate actual sobre los NEP. Ahora que NumPy está más maduro, podría ser una buena idea hacer más uso de los NEP cuando se proponen cambios que afectan la compatibilidad, especialmente si los NEP son más públicos y se pueden buscar. En segundo lugar, podríamos intentar instalar ruedas para versiones anteriores de NumPy en PyPI si eso no es demasiado trabajo. El uso de entornos virtuales parece ser la mejor idea actual para obtener reproducibilidad, y tener una selección más amplia de ruedas para descargar podría ayudar con eso.

En segundo lugar, podríamos intentar instalar ruedas para versiones anteriores de NumPy en PyPI si eso no es demasiado trabajo.

Gracias a los esfuerzos de @ matthew-brett, parece que el estado actual es que tenemos las ruedas de Windows de nuevo a 1.10 , MacOS de nuevo a 1.5 (excepto que falta 1.7 ) y Linux de nuevo a 1.6 .

La situación de MacOS / Linux parece bastante razonable. ¿Supongo que podríamos rellenar más versiones de Windows? OTOH pip install en Windows nunca solía funcionar sin esfuerzos heroicos, así que no estoy seguro de que haya una gran audiencia para esto. Ya tenemos 2 años de valor y eso irá creciendo con el tiempo.

Además, la última vez que subimos ruedas viejas, alguien se enojó con nosotros porque su flujo de trabajo asumió que no había ruedas y rompió la compatibilidad con versiones anteriores para ellos :-)

Me encantaría escuchar esa historia.

No es que realmente conozca bien estas cosas, pero creo que podemos intentar mejorar las cosas (¡aunque no estoy muy seguro de lo que eso significa!), El hecho es que tenemos que avanzar lentamente y, salvo posiblemente algunos errores, todas las versiones fueron destinado a romper el código de muy pocas personas. Creo que nuestra versión menor significa que "casi todas las personas deberían actualizar y poder actualizar sin notar nada", y creo francamente que es cierto. (Obviamente, hay cosas que afectaron a muchas personas, como depreciaciones de números enteros, pero no crean resultados incorrectos y tardaron mucho en hacerse)

Puedo ver que podría haber habido algunos cambios lo suficientemente grandes como para justificar el incremento de la versión principal, aunque, francamente, no estoy seguro de cuál sería. Y sí, tal vez haya una pérdida histórica de impulso cuando se trata de lanzamientos importantes.

En cualquier caso, tampoco puedo decir que me guste decir que (casi) cada lanzamiento es un lanzamiento importante. Entiendo que podríamos haber cabreado a la gente con algunos cambios, pero he participado de algunos cambios bastante extensos y cada vez después de explicar las razones, solo escuché que era lo correcto, y también hemos esperado años hasta que estos cambios entraron en vigor.

En cuanto a gcc, etc. Por ejemplo, no sé mucho acerca de la compilación de / C ++, me ha molestado gcc 4.8 más o menos comenzando a obligarme a descubrir cómo cambiar las banderas correctamente debido a algunas características de C ++ 11 o tan esperado, lo que provoca reacciones muy similares a los correos electrónicos que parece estar recibiendo sobre numpy, así que no estoy seguro de que sea muy diferente :).

De todos modos, no quiero discutir demasiado aquí, agradezco los comentarios sobre si podríamos ser demasiado rápidos o no lo suficientemente cuidadosos, pero debo admitir que tampoco creo que cambiar la versión principal ayude mucho con ese. Personalmente, creo que la 1.13 y la 1.6 son al menos una versión principal aparte en cierto sentido, pero no hay una única versión intermedia que pueda señalar y decir: esa fue una ruptura importante de compatibilidad para muchos usuarios.
Recuerdo haber leído comentarios en el código: "Hagamos esto en Numpy 2 tal vez", exactamente por miedo a que se rompa, con ese enfoque me temo que Numpy se habría estancado mucho y, francamente, estoy un poco orgulloso de ser parte de lo que al menos a mí me pareció una fase más activa de nuevo que era necesaria y que habría sido difícil si hubiéramos sido aún más conservadores. (Probablemente soy parcial ya que no tengo mucha idea de lo que sucedió antes de venir :)).

Lo siento, tal vez esto no tenga sentido (acabamos de tener una fiesta de Navidad). La propuesta de semver tiene sentido, pero debo admitir que no parece una solución real. Puedo estar de acuerdo con tratar de incrementar la versión principal de manera más agresiva, pero tampoco estoy de acuerdo con llamar básicamente a cada versión una versión principal. También puedo estar de acuerdo con tratar de ser más conservador en algunos casos, pero francamente no estoy muy seguro de cuáles son (solo cuente el número de RP colgados, porque nadie está seguro de si podría romper la compatibilidad en alguna parte;), estoy seguro es una buena ración)?

E incluso si he leído quejas, si traes un poco de molestias e insistencia, no es como si no deshacemos todos los cambios si es razonablemente posible o al menos lo retrasamos un año o más. Yo diría que es parte de por qué elegimos un modelo de gobernanza conservador….

Entonces, después de balbucear durante tanto tiempo:

• "Casi ningún código está roto" ¿parece estar bien para una versión menor?
• ¿Tenemos que avanzar lentamente?
• Las cosas se romperán eventualmente, y tal vez podríamos incrementar la versión principal a veces. Posiblemente incluso intente hacer algún tipo de FutureWarning cambiando más en las versiones principales. (Sinceramente, no creo que sirva de ayuda, pero estoy dispuesto a intentarlo)

Lo más importante: conozco la frustración, pero ¿hay una solución real para nosotros? ¿Crees que si incrementamos la versión principal de forma agresiva, recibirás menos correos electrónicos?

@xoviat, ¿estás preguntando por la historia sobre recibir quejas por cargar ruedas para versiones antiguas? Ese fue el # 7570.

Mi definición favorita de semver (que ya no puedo encontrar un enlace a la publicación original):

• mayor: rompimos el código de usuario a propósito
• menor: rompimos el código de usuario por accidente
• parche: rompimos las soluciones alternativas del usuario a los errores de la última versión menor

lo cual es un poco descarado, pero creo que los aciertos en algo importante, _cualquier_ cambio en el comportamiento va a quebrar a algún usuario en alguna parte. Esto es particularmente cierto con proyectos que tienen grandes superficies de API.

El primer paso, en mi opinión, es cambiar el control sobre la tasa de cambio en una instalación específica de los desarrolladores a alguien que esté más cerca del usuario final.

Creo que algo que falta en esta conversación es que las versiones anteriores de las bibliotecas siempre están disponibles (en pypi desde la fuente), por lo que si tiene un código que requiere una versión anterior de python / numpy / matplotlib, use las versiones anteriores. Los entornos de espacio de usuario hacen que esto no sea tan terrible de administrar.

Si desea utilizar nuevas versiones de las bibliotecas, debe pagar el costo de mantenerse al día con los cambios. Para impulsar la analogía del microscopio, debe realizar un mantenimiento de rutina en su microscopio o se degrada con el tiempo; el software no es diferente.

@njsmith Eso es muy gracioso. IMO # 7570 no es un problema válido dado que
NumPy cumplió con la especificación de ruedas manylinux. Generalmente, ruedas
debe cargarse para versiones anteriores, asumiendo que el tiempo es libre. Dado
que el tiempo no es gratis, simplemente podríamos notar que la gente puede construir ruedas
para una versión específica de NumPy si los quieren; enviar un PR al
repositorio de numpy-wheels. O no.

@xoviat Quiero decir, si su sistema se rompió, se rompió; ser capaz de señalar una especificación no cambia eso. En general, en estas discusiones, creo que deberíamos preocuparnos más por los efectos reales en los usuarios finales que por la pureza teórica. Pero OTOH en este caso, creo que fue la decisión correcta para mantener las ruedas arriba, dado que ya habían solucionado el problema, las ruedas ya estaban cargadas y, por lo que podemos decir, había muchas más personas beneficiándose que teniendo problemas. Pero es un recordatorio interesante de lo sutil que puede ser la "incompatibilidad hacia atrás" y de lo difícil que es establecer reglas genéricas.

@njsmith Su papel en la analogía del microscopio es el de un vendedor de microscopios que se acerca al director del laboratorio de mi colega con una oferta para reemplazar todos los microscopios del laboratorio con su último modelo, ocultando la frase "incompatible con muestras de más de 1 mm de grosor" en la letra pequeña. del contrato. Esto hace que sea muy difícil para el director del laboratorio entender que hay un punto técnico que debe discutirse con las personas que entienden esos detalles.

@rgommers Entiendo que mantener NumPy es una tarea

Por otro lado, ciertamente admito tener un par de anteojos muy particular, pero eso es cierto para todos los demás en esta discusión. Mis gafas son las de la "informática científica tradicional", que es mi entorno de trabajo. La línea de base (expectativa predeterminada) es que las actualizaciones nunca rompen nada intencionalmente. Esa es la política de los lenguajes estandarizados (C, Fortran) pero también de las bibliotecas de infraestructura (BLAS, LAPACK, MPI, ...). Sin embargo, la innovación ocurre (por ejemplo, ATLAS). Si cree que es conservador, permítame describirle lo que significa conservador en mi mundo: nunca instale una versión de nada que no tenga al menos dos años, para asegurarme de que se conocen la mayoría de los errores. Esa es una política común para las supercomputadoras cuyo tiempo es muy caro y cuyos resultados difícilmente se pueden verificar por esa razón.

Tenga en cuenta que no estoy diciendo que NumPy deba adoptar las expectativas predeterminadas de mi mundo. Simplemente digo que debería indicar claramente que es diferente.

@seberg "Casi ningún código está roto" parece estar bien en teoría para una versión menor. Pero una vez que un software adquiere estado de infraestructura (y en mi opinión, NumPy está en ese nivel), es imposible estimar cuántos desarrolladores y usuarios podrían verse afectados. El criterio entonces invariablemente se convierte en "casi nadie en quien pueda pensar está afectado", y eso no es bueno.

@tacaswell Creo que la diferencia entre "a propósito" y "por accidente" importa mucho en la práctica. Afecta la actitud de todos ante un cambio. Basta con mirar otros aspectos de la vida. Si la distinción no importara, podríamos eliminar la palabra "cuidadoso" del idioma inglés.

Bueno, francamente, creo que la idea de "reurbanización importante" está prácticamente abandonada en este momento, ya que requeriría mucho más poder de desarrollo y luego podría crear un tipo de desorden completamente diferente (ver py2 y py3 durante los primeros años).

De acuerdo, numpy es infraestructura, pero no soy un fanático de simplemente actuar como si romper el código de más personas está bien / la intención de golpear las versiones principales más rápido es una solución. Se siente más como renunciar a la tarea de hacer nuestro mejor esfuerzo para hacer lanzamientos "casi ningún código se rompe" (tal vez con la excepción "a menos que no hayas visto las advertencias para un par de lanzamientos"), y luego ayudar con la decisión de actualización.

Por lo tanto, es probable que a veces debamos reconocer que puede que no sea cierto, pero de lo contrario preferiría encontrar soluciones para asegurarnos de que no rompamos más. Por supuesto, ofreció una solución (siendo muy, muy conservador y comenzando Numpy 2 con una revisión importante), pero una vez que admitimos que esta solución simplemente no es factible sin una financiación importante o algo así, ¿qué más podemos hacer?

O déjame ser claro: si conoces a alguien capaz de seguir a Numpy Dev que pueda estar atento a ser más conservador cuando sea necesario, sabes que al menos lo aprecio. Pero personalmente no aprecio renunciar a nuestro progreso de al menos deshacernos lentamente de algunos de los rincones más oscuros en numpy para permitir el desarrollo futuro. En el mejor de los casos, terminaríamos con un NumPy muerto y un reemplazo en unos pocos años, en el peor de los casos, terminaremos siendo superados y, corriente abajo, frustrados por no poder seguir adelante y tal vez brotar "reemplazos", que por naturaleza si no ser tan maduro solo empeora las cosas.

Tengo que estar de acuerdo con @seberg sobre la creación de un espacio de nombres diferente. los
Toda la suposición detrás de esta idea es que el proyecto NumPy tiene ilimitadas
talento y recursos para mantener una biblioteca que funcione para todos.
Sin embargo, ese no es el caso. Los desarrolladores no son perfectos, por lo que normalmente
Hágalo mal la primera vez. Las personas que escriben el código numérico original.
no pudo predecir todos los escenarios en los que se usaría, y
no podía predecir el surgimiento de implementaciones alternativas, como PyPy.

Creo que la estabilidad de la API es muy importante. También creo que NumPy tiene
generalmente lo hizo bien. El hecho es que NumPy ya está
difícil de razonar (y debería serlo, dado que hasta el último gramo de
el rendimiento es importante), pero crear un espacio de nombres diferente lo haría
extremadamente difícil mantener todas las implicaciones de cambiar el código en
tu cabeza. Creo que es muy probable que si NumPy hiciera eso, habría
ser significativamente más errores debido a que los desarrolladores no entienden el
ramificaciones de cambiar el código en una interfaz en la otra.

En resumen, comprendo completamente las frustraciones de la gente. Pero como @njsmith
Dicho esto, no hay soluciones al problema que satisfagan a todos los usuarios.
Solo existen soluciones que satisfarán a la mayoría de los usuarios la mayor parte del tiempo. Y
la realidad es que si NumPy complació a la minoría de usuarios (no significa
de una manera despectiva) que exigía estabilidad API por encima de todo, el
La financiación de NUMFOCUS podría agotarse porque no estaría claro cuál es el dinero
fue utilizado, y luego, ¿dónde estaríamos? Probablemente en una situación donde
MMTK ya no puede depender de NumPy, al igual que la situación en la que podría
ya no dependen de Numeric.

Pondría el código actual en modo de mantenimiento mínimo y comenzaría con un rediseño importante en un espacio de nombres diferente, dejando que lo antiguo y lo nuevo coexistan indefinidamente con la interoperabilidad a través de la interfaz del búfer. Y sí, sé que esto no es un esfuerzo trivial por muchas razones, pero creo que es la única forma de salir del montón de deuda técnica acumulada. El objetivo principal del rediseño sería la mantenibilidad.

De hecho, estoy de acuerdo con usted, pero no veo cómo es factible sin una gran inyección de financiación / visión. NumPy constituye un gran volumen de trabajo. Tal vez @teoliphant y @skrah lo plures , pero será una batalla cuesta arriba.

Dado el NumPy que tenemos hoy, creo que lo estamos haciendo tan bien como razonablemente podemos.

Para aquellos que respondieron "sí", segunda pregunta: ¿pueden nombrar algún software que no sea Numpy que haya hecho esto alguna vez?

django es otra pieza de software notable que no usa versiones semánticas. Usan cambios importantes para indicar interrupciones sustanciales, pero desaprueban las cosas en cambios .x después de un largo período de advertencias. Más o menos como NumPy.

De hecho, estoy de acuerdo contigo

@shoyer por interés, ¿por qué? ¿Cómo no se convertiría eso en una transición similar a py3k muy dolorosa a la nueva base de código en algún momento?

Esa es la política de los lenguajes estandarizados (C, Fortran) pero también de las bibliotecas de infraestructura (BLAS, LAPACK, MPI, ...). Sin embargo, la innovación ocurre (por ejemplo, ATLAS).

La innovación al ritmo de LAPACK / ATLAS / OpenBLAS es una receta para que NumPy se vuelva irrelevante mucho más rápido de lo que sería de otra manera.

Mire, debe quedar claro para usted a partir de todas las respuestas que este cambio de versiones no va a suceder, y ese es el consenso entre los ~ 7 desarrolladores centrales activos más algunos desarrolladores de los principales proyectos posteriores. Si necesita una estabilidad absoluta, probablemente sea mejor que fije una versión fija en sus sistemas durante algunos años y eduque a sus administradores de sistemas al respecto.

¿Cómo no se convertiría eso en una transición similar a py3k muy dolorosa a la nueva base de código en algún momento?

La gran diferencia es que, si bien Python 3 es un interruptor de todo / nada (para programas de Python), es fácil o al menos factible mezclar / combinar diferentes bibliotecas ndarray. La interfaz de búfer significa que puede transferir datos de un lado a otro sin copias. Si coacciona las entradas a sus funciones con np.asarray() es posible que ni siquiera note si alguna biblioteca con la que está trabajando cambia para devolver matrices de un tipo diferente.

Esto suena como partes repetidas de numeric / numarray / numpy
experiencia, que tampoco fue muy agradable (la interfaz del búfer
ayuda, pero creo que dicha transición seguirá implicando código manual
cambios, no todos triviales). Tampoco será posible
para bibliotecas como Scipy para "actualizar" a la "nueva matriz" sin
rompiendo la compatibilidad con versiones anteriores, por lo que el problema simplemente surge en
el ecosistema, lo que obliga a otras bibliotecas a tomar una decisión similar para
abandonar los espacios de nombres antiguos.

Si todo el mundo coaccionara sus entradas con np.asarray , entonces np.matrix no sería un problema :-).

Si diferentes bibliotecas de arreglos pueden ponerse de acuerdo sobre los tipos de pato y restringimos a los tipos representables por el protocolo de búfer, entonces puede funcionar. Pero si el objetivo de una reescritura fuera hacer cambios de interfaz incompatibles en los objetos de la matriz e implementar nuevos tipos de dtypes, ... realmente no veo cómo hacer que funcione. Ejemplo concreto: una cosa obvia a corregir en este tipo de reescritura sería el comportamiento de ndarray.dot en entradas de alta dimensión. Pero si hay una biblioteca que hace def f(a, b): a.dot(b) , entonces crear una biblioteca de este tipo podría romperla. Realmente no importa si esa biblioteca se llama numpy o no.

Y eso es incluso antes de entrar en la imposibilidad general de reescribir todo en un big bang, mantener la atención de los desarrolladores mientras hacemos eso, y no solo hacerlo bien, sino mejorar tanto que pueda convencer a las personas de migrar, todo sin retroalimentación incremental de los usuarios. Creo que dynd es un ejemplo instructivo aquí.

@rgommers Por favor leer de nuevo lo que escribió: Yo no, no repetir, propongo que NumPy debe adoptar el ritmo de LAPACK. Propongo que indique claramente a las personas que tienen tal expectativa (es decir, el 80% de las personas en mi entorno) que no es así.

@njsmith Un aspecto importante de un rediseño, como yo veo, sería abandonar OO. No es un buen enfoque para estructurar código para una única estructura de datos con toneladas de funciones que funcionan en ella. Escriba np.dot(a, b) y el problema que describe se evaporará instantáneamente. Puede tener cualquier cantidad de implementaciones de namespace.dot desee. Cada biblioteca puede usar la que le guste, y aún pueden interoperar. Es OO el que crea un espacio de nombres único para los métodos, y eso es un problema.

Sí, eso es una ruptura importante con los hábitos de Python. Y sí, será complicado implementar operadores además de eso. Pero creo que se puede hacer y creo que vale la pena el esfuerzo.

Solo para demostrar que puedo estar a favor de romper cosas ;-)

@rgommers Por favor, vuelva a leer lo que escribí: No, no repito, propongo que NumPy adopte el ritmo de LAPACK.

Entiendo que. Los dos párrafos de mi respuesta no estaban directamente relacionados, lo siento si eso fue confuso.

Propongo que indique claramente a las personas que tienen tal expectativa (es decir, el 80% de las personas en mi entorno) que no es así.

Eso es lo que estaba diciendo, el consenso parece ser que su propuesta será rechazada. Tendrás que simplemente solicitar una versión anclada a ese 80% y explicar por qué eso es lo que quieres.

@khinsen De acuerdo, entonces finja que mi ejemplo fue los cambios incompatibles en la indexación que seguramente haríamos si fuera posible. (La indexación elegante tiene algunos casos de esquina extraordinariamente confusos).

@njsmith El mismo problema, en cierto modo. La indexación es una llamada a un método en Python, por lo que es OO nuevamente.

Comentario adicional: La indexación elegante es el mayor error de diseño en NumPy, en mi opinión, porque ni siquiera tiene (y nunca tuvo) una especificación inequívoca. Hace np.take para argumentos enteros y np.repeat para argumentos booleanos. Dado que los booleanos son un subtipo de números enteros en Python, esto crea una ambigüedad para los argumentos que contienen solo 0 y 1.

De hecho, existe una relación con el tema de este hilo, porque este es exactamente el tipo de error de diseño que ocurre cuando el desarrollo avanza demasiado rápido.

Hablo de la indexación elegante en mis cursos de SciPy exclusivamente para decirle a la gente que no la use. Hay np.take y np.repeat que funcionan perfectamente bien y no causan problemas. Y si los usa como funciones en lugar de métodos, tampoco hay problema de OO. Para aquellos a los que no les gusta np.repeat porque el nombre no sugiere la intención cuando se usa con booleanos, simplemente introduzca un alias: select = np.repeat . Una vez más, algo que OO hizo innecesariamente difícil.

Tenga en cuenta también que la indexación simple no está sujeta a ningún problema de este tipo. Hace lo que casi todo el mundo esperaría que hiciera en todas las circunstancias posibles, por lo que se puede implementar en un método.

El tema espinoso desde mi punto de vista es la aritmética. Desea escribir a+b para la adición de matriz, en lugar de np.add(a, b) , pero no hay un acuerdo universal sobre qué debe hacer exactamente a+b , en particular en términos del resultado dtype . Ese fue uno de los problemas centrales de la división Numeric / numarray, que llevó a la introducción de nuevos tipos escalares en NumPy, y esos también causan una buena cantidad de sorpresas desagradables. Creo que este problema se puede resolver, pero no en comentarios paralelos sobre un tema de discusión de GitHub.

@rgommers Si "solicitar una versión

Este es el punto que intento hacer al insistir en que NumPy sea un software de infraestructura. Para muchas personas, es solo uno de los cientos de ladrillos lego que componen su instalación de software. No les importa específicamente, solo necesita estar ahí y "funcionar".

No quiero descarrilar esto mucho más, pero no tengo idea de a qué te refieres con las matrices np.repeat y bool

@ eric-wieser repite 0 veces y lo eliminas de la matriz, 1 veces y permanece. No estoy de acuerdo con enseñar esto en lugar de indexar, pero lo que sea (la peor rareza se ha ido hoy en día, así que sí, en numpy, un bool no es un int en la mayoría de los casos, aceptando eso, estás bien ahora, creo, así que eso es incluso una incompatibilidad con listas si desea verlo así, pero ...).

Un punto al margen, ya que esto ya no va a ninguna parte :). De hecho, espero un poco que arreglar las cosas lentamente en numpy hará que sea más fácil en algún momento en el futuro hacer que numpy sea más reemplazable.

Su sugerencia es un poco como "solicitar a los usuarios de Windows que se cambien a Linux" (o viceversa).

Hmm, preguntarle a las personas que son técnicamente competentes (espero ...) que aprendan cómo funcionan realmente los números de versión en el mundo real no es nada como un cambio de Windows a Linux.

Este es el punto que intento hacer al insistir en que NumPy sea un software de infraestructura.

Y presumiblemente, si hiciéramos este cambio, ¿pasará a SciPy porque es la siguiente parte de la infraestructura? ¿Cuándo deja de ser infraestructura? ¿Y por qué NumPy y las otras partes de la infraestructura querrían tener un esquema de control de versiones completamente diferente del propio Python y del resto de todo el ecosistema científico de Python?

Ese 80% "no es una comunidad organizada con la que puedas hablar.

Los administradores de la (s) supercomputadora (es) que usa realmente deberían hablar entre ellos, ¿verdad? No puede haber una gran cantidad de gente corriendo de un lado a otro actualizando el software en esos dos sistemas y sin hablar nunca. No quise decir que debas educar al 80% de todos los administradores de sistemas en todo el mundo, solo a los que necesitas.

@seberg Declarar que las listas y las matrices son tipos de datos diferentes que solo comparten la indexación como una propiedad común es un punto de vista válido para adoptar. También facilitaría la explicación de la existencia de escalares NumPy específicos. Pero no he visto ninguna presentación de NumPy que adopte este punto de vista.

@rgommers

Los administradores de la (s) supercomputadora (es) que usa realmente deberían hablar entre ellos, ¿verdad?

No. Ni siquiera conocen la existencia de los demás. Trabajan para diferentes organizaciones en diferentes lugares, cuyo único punto en común es tener algunos usuarios en común.

No quise decir que debas educar al 80% de todos los administradores de sistemas en todo el mundo, solo a los que necesitas.

No se trata de mí, tengo una solución que funciona perfectamente para mí: siempre instalo Python más todas las bibliotecas de la fuente, en mi directorio personal.

De lo que se trata es de las personas con las que colaboro y las personas que me piden ayuda (por ejemplo, porque participaron en uno de mis cursos de Python en el pasado). No tienen la competencia técnica para administrar su propia instalación de Python y se lo delegan a otra persona (administrador o colega con más experiencia).

para aprender cómo funcionan realmente los números de versión en el mundo real

En la cultura de fondo compartida de las personas en las que estoy pensando, el mundo real en realidad funciona como una versión semántica o una aproximación cercana.

En la cultura de fondo compartida de las personas en las que estoy pensando, el mundo real en realidad funciona como una versión semántica o una aproximación cercana.

Eso es porque usan un número limitado de bibliotecas, en su mayoría de movimiento lento como LAPACK & co. Como señaló @njsmith , la mayoría del software tiene números de versión bajos porque no usan versiones semánticas.

@rgommers Usan principalmente bibliotecas de movimiento lento, aunque yo no diría "un número pequeño".

Como señaló @njsmith , la mayoría del software tiene números de versión bajos porque no usan versiones semánticas.

No en mi experiencia. Pero entonces, "mayoría" probablemente significa "la mayoría de los que conozco", tanto para ti como para mí, y probablemente haya poca superposición entre los paquetes que usas y los paquetes que uso, fuera del ecosistema SciPy.

Y presumiblemente, si hiciéramos este cambio, ¿pasará a SciPy porque es la siguiente parte de la infraestructura? ¿Cuándo deja de ser infraestructura?

De hecho, preferiría que SciPy y el resto de los fundamentos del ecosistema SciPy adopten los mismos principios, pero personalmente no invertiré ningún esfuerzo en defender esto en ningún otro lugar que no sea NumPy, que se usa mucho más ampliamente que cualquiera de los las otras bibliotecas, y también mucho más fundamental. Los arreglos NumPy son la estructura de datos central para gran parte del software científico, mientras que SciPy es solo una gran colección de funciones de las cuales cualquier aplicación usa un pequeño subconjunto.

Tenga en cuenta también que SciPy utiliza de facto el control de versiones semántico, aunque probablemente no de forma intencionada, porque acaba de llegar a 1.0.

¿Y por qué NumPy y las otras partes de la infraestructura querrían tener un esquema de control de versiones completamente diferente del propio Python y del resto de todo el ecosistema científico de Python?

De hecho, todo el ecosistema de SciPy debería utilizar el mismo enfoque, el que es (como yo lo veo) el dominante en la informática científica. Esto no se aplica a las bibliotecas Python y Python de otros dominios, que tienen hábitos diferentes. El desarrollo web, por ejemplo, es mucho menos conservador que la informática científica. También lo hacen principalmente diferentes personas, que se preocupan por diferentes usuarios. El lenguaje Python sería el único punto de contacto.

Los arreglos NumPy son la estructura de datos central para gran parte del software científico, mientras que SciPy es solo una gran colección de funciones de las cuales cualquier aplicación usa un pequeño subconjunto.

Y la estructura de datos central es estable. La gran mayoría de los cambios incompatibles en cualquier versión son casos extremos y, en su mayoría, no en el comportamiento de ndarray. Consulte https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes, por ejemplo. Tenga en cuenta también que ninguno de esos cambios tendría ningún significado para un administrador de sistemas, por lo que incluso si miraran esas notas durante mucho tiempo (si eso hubiera sido 2.0.0), no podrían decidir si una actualización está bien o no.

Tenga en cuenta también que SciPy utiliza de facto el control de versiones semántico, aunque probablemente no de forma intencionada, porque acaba de llegar a 1.0.

SciPy utiliza exactamente el mismo esquema de control de versiones y política de eliminación / desactivación que NumPy. Estar en 0.x durante mucho tiempo no implica semver.

el que es (como yo lo veo) el dominante en computación científica

Las comparaciones tradicionales del ecosistema SciPy son con cosas como Matlab y R. No puedo encontrar ninguna información sobre R, pero está en 3.xy ha evolucionado mucho, así que probablemente no semver. Matlab: definitivamente no semver.

RE: indexación elegante. De hecho, esto podría usar una función dedicada. Esto es lo que se hizo en TensorFlow, por ejemplo, con tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask , etc. El resultado es un poco más detallado que sobrecargando [] , pero ciertamente más transparente.

Otra característica que puede ayudar son las anotaciones de tipo, una característica que fue parcialmente motivada por la dificultad de la transición de Python 2 a 3.

No digo que esto sea fácil. En mi opinión, las consecuencias para la comunidad son más importantes. De hecho, esto requeriría mucha energía para implementar y luego impulsar proyectos como SciPy.

@khinsen He estado siguiendo la discusión toda la semana y creo que tengo un problema de prueba práctica para poner a prueba tu opinión. Este podría ser un buen elemento para ver cómo su perspectiva manejaría tales conflictos en lugar de la discusión ligeramente abstracta hasta ahora.

Actualmente, gracias al marco Apple Accelerate, la versión mínima de LAPACK requerida es 3.1.ish, que data de hace más de una década. Y actualmente LAPACK está en 3.8.0. Mientras tanto, han descartado una gran cantidad de rutinas (obsoletas y / o eliminadas) y han solucionado muchos errores y, lo más importante, han introducido nuevas rutinas que son necesarias para llenar el vacío entre el software comercial y el software científico Python. El resultado final se resume aquí . He estado molestando constantemente principalmente a @rgommers y a otros durante los últimos 6 meses por esto 😃 y puedo asegurarles que si fueran el tipo de personas que, tal vez de mala gana, retrataste aquí, esto debería haber sucedido a estas alturas y rompió el código de muchos. personas. En cambio, han estado explicando pacientemente por qué no es tan fácil abandonar el apoyo a Accelerate.

Ahora existe una necesidad indiscutible de versiones más nuevas. Esa no es la discusión y podemos saltarnos esa parte con seguridad. Hay una parte significativa de usuarios de NumPy y SciPy que se beneficiarían de esto. Pero no podemos simplemente dejarlo por los argumentos que ya ha presentado. ¿Cómo resolverías esto?

No estoy preguntando esto de manera sarcástica, pero dado que todos los desarrolladores aparentemente piensan igual (y debo decir que estoy de acuerdo con ellos), tal vez tu apariencia pueda dar una nueva idea. ¿Deberíamos mantener Accelerate y crear un nuevo paquete NumPy / SciPy cada vez que suceda algo así? Si dejamos el soporte para innovar, ¿cuál es la mejor manera de hacerlo?

Actualmente, gracias al marco Apple Accelerate, la versión mínima de LAPACK requerida es 3.1.ish

@mhvk , esto podría ser un problema para # 9976 en 1,14, que creo que necesita 3.2.2 (editar: muevamos la discusión allí)

@xoviat : Tengamos esta discusión sobre ese tema

@ilayn ¡ Gracias por

El principal punto común: hay diferentes usuarios / comunidades que tienen diferentes necesidades. Algunos quieren Accelerate, otros quieren las nuevas funciones de LAPACK. Ambos tienen buenas razones para sus prioridades específicas. Incluso puede haber personas que quieran tanto Accelerate como las nuevas funciones de LAPACK, aunque esto no me queda claro.

En el mundo de Fortran / C, no existe tal problema porque las pilas de software son menos profundas. Hay Fortran, LAPACK y el código de la aplicación, sin intermediarios adicionales. Lo que sucede es que cada código de aplicación elige una versión particular de LAPACK en función de sus prioridades. Los centros de cómputo suelen mantener varias versiones de LAPACK en paralelo, cada una en su propio directorio, y la elección se realiza modificando el código de la aplicación Makefile .

La lección que podemos y debemos asumir en el ecosistema SciPy es que la elección de las versiones de software no es tarea de los desarrolladores de software, sino de las personas que ensamblan paquetes de software específicos para aplicaciones. En nuestro mundo, esa es la gente que trabaja en Anaconda, Debian y otras distribuciones de software, pero también administradores de sistemas en varios niveles y usuarios finales con la competencia y motivación adecuadas.

Entonces, mi propuesta para el dilema SciPy / LAPACK es mantener SciPy actual usando Accelerate, pero ponerlo en modo de mantenimiento mínimo (posiblemente asumido por diferentes personas). Las personas que quieran Accelerate pueden elegir "SciPy 2017" y ser felices. No obtendrán las nuevas funciones de LAPACK, pero presumiblemente eso está bien con la mayoría de ellos. El desarrollo continúa en un nuevo espacio de nombres ( scipy2 , scipy2018 o lo que sea), que cambia al LAPACK moderno. Si es técnicamente posible, permita la instalación paralela de estas dos (y futuras) variantes (que creo que deberían ser posibles para SciPy). De lo contrario, las personas que necesiten ambos tendrán que utilizar varios entornos (conda, venv o entornos de todo el sistema a través de Nix o Guix). Tenga en cuenta que incluso en este segundo escenario, recomiendo encarecidamente cambiar el espacio de nombres con cada cambio incompatible, para asegurarse de que los lectores de código Python en cualquier nivel comprendan para qué versión de SciPy se escribió el código.

La idea general es que los desarrolladores propongan cosas nuevas (y se concentren en su desarrollo), pero no las anuncien como "mejores" en un sentido general, ni como un reemplazo universal. Elegir la combinación correcta de versiones de software para una tarea en particular no es su trabajo, es el de otra persona.

La idea general de que el desarrollo y el montaje se realizan de forma independiente y por diferentes personas también sugiere que los megapaquetes de hoy en día deberían dividirse en unidades más pequeñas que puedan progresar a diferentes ritmos. Hoy en día, no hay ninguna razón para que NumPy contenga una pequeña interfaz LAPACK y herramientas como f2py . Para SciPy, puede tener sentido tener un espacio de nombres común que indique coherencia y una política de desarrollo común, pero los subpaquetes podrían distribuirse de forma independiente. El enfoque de mega-paquete se remonta al lema "baterías incluidas" de Python, que era genial hace 20 años. La base de usuarios de hoy es demasiado diversa para eso, y el empaquetado de software generalmente se ha reconocido como una actividad distinta. Incluir las baterías ahora debería ser el trabajo de Anaconda.

El principal obstáculo para adoptar este enfoque son las distribuciones tradicionales de Linux como Debian o Fedora con su enfoque de "una instalación de Python por máquina". Creo que podrían cambiar a múltiples entornos virtuales de todo el sistema con un esfuerzo razonable, pero no he pensado mucho en esto. Para mí, el futuro de los paquetes de software son los sistemas basados ​​en el entorno como conda o Guix.

No veo cómo todas las preposiciones que ha presentado hasta ahora son compatibles con alguno de estos pasos

• Acabas de recrear la locura de la siguiente imagen
  
  Acabo de contar y ahora tengo 27 copias en mi máquina con Windows. Ahora multiplique eso por 10 ya que (los lanzamientos son más frecuentes aquí) y por 2 (ya que los ciclos de lanzamiento de NumPy y SciPy son independientes). En el año 2025 tendré fácilmente 15 copias de cada biblioteca y 10 LAPACK y 5 f2pys como dependencias. Por no hablar de la carga de mantenimiento de solo una docena de personas en ambos paquetes, esto simplemente no funcionará. (C ++ no es relevante, inserte cualquier lib estándar de cualquier cosa). Pregúntele a cualquier desarrollador de código comercial por Win y dígale que es una buena idea. No soy responsable de lo que sigue en ese intercambio.
• Luego aumentó la granularidad de los paquetes y ahora todos hacen las cosas por su cuenta con diferentes versiones de paquetes; f2py rompió algo en una versión, por lo que SciPy deja de compilar en la siguiente, pero aún depende de la versión anterior de NumPy. Entonces, alguna entidad holística debería reunirlos gratis.
• Luego también hiciste de Anaconda (o alguna otra entidad) una empresa de gran dependencia, como lo era Accelerate. O simplemente habrá una abundancia de "alguien más".
• Luego, movilizó la mayor parte de la base de usuarios en un flujo de trabajo que realmente no quieren (incluido yo mismo) que involucre envs virtuales.
• Luego, incluso modificó los sistemas operativos Linux de pasada (que es ... quiero decir, simplemente leer algunas de sus listas de correo, es divertido).

Quizás te desviaste un poco.

(Esto se ha convertido en una discusión gratuita para todos, así que seguiré adelante y participaré).

El problema de mantener el soporte para la aceleración no es que carece de API LAPACK más nuevas. Si ese fuera el problema, podríamos enviar calzas LAPACK más nuevas y listo. El problema es que existen funciones básicas que devuelven resultados incorrectos en determinados escenarios. No hay forma de evitar eso que no sea escribir nuestras propias funciones BLAS. Y si estamos haciendo eso, también podríamos requerir OpenBLAS o MKL.

@xoviat Todos estos se han discutido en https://github.com/scipy/scipy/pull/6051. Como siempre, nunca es tan simple. Pero el punto no es discutir Accelerate drop, sino usarlo como un caso de uso para el ciclo de desarrollo real para nuevas versiones.

@ilayn Sí, estoy seguro de que ya sé los puntos que estoy

Se podría argumentar que una característica (o limitación) del ecosistema Python es que obtienes una versión de una biblioteca sin el horrible truco de alterar los nombres. Esto sucede en el núcleo de Python. Es por eso que hay bibliotecas llamadas _lib_ y _lib_ 2 que tienen el mismo propósito pero diferencias de API. Incluso Python funciona de esta manera. No es posible mezclar bibliotecas estándar entre versiones, incluso si ambas son técnicamente utilizables en el Python moderno sin que alguien las extraiga y las ponga en PyPi. Hay muchas preguntas de

@ilayn Si por alguna razón quieres tener todas las combinaciones posibles de todas las versiones de todo en tu máquina, sí, eso es un desastre. Pero, ¿por qué querrías eso? Si se limita a las combinaciones que realmente necesita para los escenarios de su aplicación, apuesto a que serán menos. Como ejemplo, mantengo exactamente dos entornos de Python en mi máquina: uno con Python 2 + NumPy 1.8.2 para ejecutar mi código de 20 años, y otro que representa el estado del arte de hace unos dos años para todo lo demás ( hace dos años porque lo configuré hace dos años y nunca vi una razón para actualizar después de eso).

En cuanto a la granularidad, quizás no fui muy claro en mi propuesta. Lo que defiendo es una mayor granularidad en el empaque, no en el desarrollo. Espero que el desarrollo de, digamos, f2py y SciPy continúe en estrecha coordinación. f2py-2018 y SciPy-2018 deberían funcionar juntos. Eso no significa que tengan que empaquetarse como una sola entidad. El objetivo es brindar más libertad a los gerentes de distribución de software para que hagan su trabajo.

Definitivamente no quiero hacer que Anaconda o cualquier otra distribución sea una dependencia. Es más como la "abundancia de otra persona", aunque no espero que la cantidad de distribuciones crezca hasta la "abundancia", dado que ensamblarlas es mucho trabajo.

No tengo idea de qué flujo de trabajo quiere "la base de usuarios". Veo muchas bases de usuarios diferentes con diferentes requisitos. Personalmente, optaría por varios entornos, pero si hay una base de usuarios significativa que quiere un solo entorno por máquina, alguna distribución se encargará de eso. Pero los entornos virtuales se inventaron por una razón, resuelven un problema real. Las distribuciones a nivel de sistema como Nix o Guix los llevan a otro nivel. No espero que se vayan.

Por cierto, estoy siguiendo la lista de correo de una distribución de Linux (Guix). No es muy divertido, pero sí mucho trabajo con los pies en la tierra. Estoy feliz de que haya gente haciendo esto.

@xoviat No

Realmente se trata de etiquetado y comunicación. Quiero alejarme de la imagen idealizada del software que sigue un camino lineal de progreso, con las versiones más nuevas siendo "mejores" como lo indican los números de versión "más altos". Quiero reemplazar esta imagen por una que considere más realista: no existe una relación de orden obvia entre las versiones de software. Los producidos por una comunidad de desarrolladores coherente de larga duración tienen un orden temporal, pero eso no implica nada sobre la calidad o idoneidad para una aplicación determinada.

Si la imagen idealizada fuera correcta, no veríamos bifurcaciones y no tendríamos entornos virtuales. Tampoco proyectos como VersionClimber .

Lo que propongo es que los desarrolladores de software deberían aceptar esta realidad en lugar de negarla. Deben desarrollar (y, sobre todo, empaquetar y etiquetar) sus productos para un mundo de diversidad.

@khinsen Si está de acuerdo con los resultados incorrectos de las funciones de álgebra lineal, entonces podemos mantener el soporte acelerado (nota para los demás: sé cómo hacer esto). Sin embargo, el principal problema es que es posible que seas la única persona que quiera esto. E incluso si no es así, ¿qué sucede cuando alguien en el camino culpa a SciPy por un problema con la aceleración? ¿Qué pasa cuando alguien quiere tener su pastel y comérselo también? Puedo ver que eso está sucediendo.

@xoviat No, no estoy de acuerdo con los resultados incorrectos de las funciones de álgebra lineal. Pero estoy seguro de que hay muchos usuarios de SciPy que no necesitan las funciones afectadas en absoluto. En el hilo al que se refirió, alguien sugirió eliminar / desactivar las funciones afectadas cuando se detecta Accelerate, lo cual creo que es una buena solución (nota: no puedo juzgar el esfuerzo requerido para implementar esto).

En cierto modo, esto es parte del problema del megapaquete. Con una distribución más granular, sería más fácil elegir las cosas que funcionan, tanto a nivel de desarrollo como de ensamblaje de distribución. Incluso se podría imaginar un ensamblador de distribución que componga una distribución SciPy específica de dominio y plataforma en la que diferentes subpaquetes usan diferentes versiones de LAPACK, por ejemplo, para su uso en contextos HPC.

Pero estoy seguro de que hay muchos usuarios de SciPy que no necesitan las funciones afectadas en absoluto.

Hay evidencia mínima para esta afirmación y, de hecho, apostaría por lo contrario. Las funciones se utilizan ampliamente pero solo fallan en ciertos escenarios; en otras palabras, sus resultados probablemente sean correctos, pero pueden no serlo. Sí, esto probablemente se aplica al SciPy que tiene instalado actualmente si usa OSX. Sí, esto debe solucionarse.

En cuanto a mantener una rama separada, no creo que nadie se oponga a darle acceso de escritura a una rama en particular para que la mantenga. Pero este es un software de código abierto y la gente trabaja en lo que quiere; Soy escéptico de que muchas personas estén interesadas en mantener esa rama.

En realidad, creo que la anaconda SciPy está compilada con MKL, por lo que no te verías afectado en ese caso. Pero entonces, ¿por qué le importaría acelerar el soporte?

@xoviat Parece que hay un gran malentendido aquí. No tengo ningún interés personal en absoluto en este tema específico. No utilizo ninguna rutina de álgebra lineal de SciPy.

Señalaste un hilo sobre un tema de SciPy y me preguntaste cómo manejaría ese tipo de situación. El hilo muestra claramente una renuencia a simplemente eliminar el soporte de Accelerate, de lo cual deduje que hay un grupo de usuarios significativo que se vería afectado por tal cambio. Si ese grupo de usuarios no existe, ¿dónde está el problema? ¿Por qué SciPy no ha abandonado el soporte de Accelerate?

@xoviat Mantener una sucursal separada es fácil para cualquiera. No es necesario que esté alojado en el mismo repositorio de GitHub. En otras palabras, las sucursales no son el problema. El problema es el espacio de nombres, para que la existencia paralela de versiones de SciPy separadas sea transparente para los usuarios (y los ensambladores de distribución).

Hoy en día, cuando ve un código que dice "import scipy", no tiene idea para qué rango de versiones de SciPy se supone que funciona (es decir, ha sido probado hasta cierto punto). En el mejor de los casos, hay un archivo README que dice "SciPy> = 0.8" o algo así. Este hábito se basa en la suposición de que las versiones "superiores" son siempre "mejores" y nunca degradan (rompen, ralentizan, ...) nada. Y esa suposición es simplemente incorrecta.

Si, por otro lado, el código dice "importar scipy2017 como scipy", entonces está claro para todos los lectores que usarlo con versiones anteriores o posteriores puede llevar a malas sorpresas. Y si las versiones antiguas de SciPy desaparecen (efectivamente, por falta de mantenimiento), dicho código fallará con un mensaje de error, en lugar de continuar funcionando de manera poco confiable.

Este es el único punto que estoy tratando de hacer en este hilo. La convivencia de diferentes versiones es una realidad. La idea de que cuanto más alto es mejor es un sueño. Seamos realistas y organizémonos para el mundo real, reconociendo un universo de múltiples versiones y ajustando la comunicación de todos para evitar malentendidos.

Bueno, no sé… en mi opinión cuando se trata de advertencias, la importación de una versión específica no es una advertencia, es prohibitivo usar una versión diferente, ya que los usuarios que tengan problemas como usted describe no se atreverán a cambiar su código. Una advertencia sería si imprime una advertencia en la instalación / tiempo de ejecución que no se ha probado para todas las versiones, excepto para las específicas.

Supongo que es posible crear ese tipo de paquetes adicionales. También espero que solo cree un tipo diferente de infierno. Mucho podría sobrevivir, pero la verificación de tipos, por ejemplo, no lo hará ni podrá hacerlo cuando mezcle dos versiones, por lo que básicamente no sabrá si puede o no funcionar hasta que lo intente (¡y nadie lo probará!).
Y a menos que sugiera permitir mezclar dos versiones, creo que su solución scipy2017 solo empeorará las cosas. Parece más bien que necesitaríamos algo como la elección de entorno virtual dinámico / en tiempo de ejecución (como pin_import_version("1.6<numpy<1.10", level="raise") antes de cualquier importación en el nivel de Python).

La importación específica tiene sentido si tiene cambios prohibitivos importantes (un poco como py2 / py3), y ya vimos que tenemos opiniones diferentes sobre dónde o en qué escala de tiempo parece estar esa línea "principal".

Se ha enviado la compatibilidad con versiones anteriores NEP # 11596, ¿podemos cerrar esto?

Se ha enviado la compatibilidad con versiones anteriores NEP # 11596, ¿podemos cerrar esto?

Sí, podemos cerrar esto. Independientemente de ese NEP (que menciona explícitamente semver como una alternativa rechazada), el consenso de los desarrolladores principales aquí es que no queremos cambiar a semver. Por lo tanto, cerrando como no se arregla.

Gracias a todos por la discusión.