Numpy: Demande: utiliser le versionnage sémantique

Numpy pourrait-il être considéré comme utilisant le contrôle de version sémantique, mais avec un 1 début?

Notez que presque tous les projets scientifiques de base Python font ce que NumPy fait: supprimer le code obsolète après quelques versions, sauf si cela est très perturbateur, et ne modifier le numéro de version majeur que pour les choses majeures.

Vous ne savez pas si vous proposez une modification de la politique de dépréciation, ou si vous pensez que nous devrions être à la version 14.0.0 au lieu de 1.14.09 maintenant.

Le dernier: NumPy devrait être à peu près à la version 14 maintenant. Mais je propose d'adopter cette convention uniquement pour les versions futures.

BTW: Le prédécesseur de NumPy, Numeric, a utilisé le versionnage sémantique et est arrivé à la version 24 sur environ une décennie. Je ne sais pas pourquoi cela a été changé lors de la transition vers NumPy.

J'ai l'impression que la grande majorité des projets Python n'utilisent pas le versionnage sémantique. Par exemple, Python lui-même n'utilise pas le contrôle de version sémantique. (Je ne connais pas non plus de systèmes d'exploitation ou de compilateurs traditionnels utilisant semver - en avez-vous en tête?) Je conviens que les partisans de semver ont fait un excellent travail de marketing, amenant de nombreux développeurs à penser que c'est idée, mais AFAICT est essentiellement irréalisable dans le monde réel pour tout projet plus grand que le pavé gauche, et je conteste fortement l'idée que les gens de semver "possèdent" maintenant le format traditionnel MAJOR.MINOR.MICRO et que tout le monde doit passer à quelque chose autre.

Pouvez-vous donner un exemple de ce que vous entendez par "un schéma d'étiquetage de version qui ne peut pas être confondu avec le contrôle de version sémantique"? Utiliser des noms plutôt que des chiffres? Vous citez le contrôle de version basé sur la date, mais le schéma le plus courant pour cela que j'ai vu est celui utilisé par exemple par Twisted et PyOpenSSL, qui sont actuellement à 17.9.0 et 17.5.0, respectivement. Celles-ci ressemblent à des versions semver totalement plausibles pour moi ...

Et pouvez-vous préciser quel avantage cela aurait pour les utilisateurs? Dans cet avenir hypothétique, chaque version comporterait des changements de rupture qui ne sont pas pertinents pour la majorité des utilisateurs, comme maintenant. Quelles informations utiles pourrions-nous transmettre en augmentant le nombre majeur tous les quelques mois? "Cela brise probablement quelqu'un, mais ne vous brise probablement pas"? Devrions-nous également remplacer la version majeure des versions de correction de bogues, étant donné l'inévitabilité historique qu'une grande partie d'entre elles brisera le code d'au moins 1 personne? Pouvez-vous donner des exemples de «développeurs de logiciels, d’utilisateurs de logiciels et de gestionnaires de distributions de logiciels» qui ont en fait été confus?

Notez que la liste de diffusion est un lieu plus approprié pour cette discussion et que nous devrons probablement y avoir une discussion avant d'apporter des modifications, mais les commentaires ici devraient être utiles pour avoir une idée du type de problèmes que vous souhaitez à aborder dans cette discussion.

@njsmith Il semble que le seul point factuel sur lequel nous ne sommes pas d'accord est de savoir si le versionnage sémantique est ou non l'hypothèse par défaut aujourd'hui. Cela nécessite une définition plus claire de la communauté dans laquelle il est (ou non) la valeur par défaut. Les niveaux de gestion des logiciels qui me tiennent à cœur sont la gestion de la distribution et l'administration des systèmes, où les gens décident quelle version est la plus appropriée dans leur contexte.

L'enquête informelle qui m'a conduit à la conclusion que le versionnage sémantique est la valeur par défaut consistait à parler aux administrateurs d'installations informatiques scientifiques. J'ai aussi envisagé
une approche plus empirique (lister les paquets sur une installation Debian récente et en choisir quelques-uns au hasard pour étudier leur approche de versionnage), mais cela s'est avéré très difficile, car peu de projets indiquent clairement s'ils utilisent ou non le versionnage sémantique.

Un commentaire d'un administrateur système m'a particulièrement frappé comme pertinent: il a dit que pour décider de la version à installer, toute convention autre que le versionnage sémantique est inutile. Les administrateurs système ne peuvent ni explorer chaque package en détail (ils manquent de temps et de compétence) ni consulter tous leurs utilisateurs (trop nombreux). Ils doivent adopter une politique uniforme, ce qui tend à être basé sur l'hypothèse d'un versionnage sémantique. Par exemple, un administrateur d'un cluster informatique m'a dit qu'il vérifie avec quelques "utilisateurs expérimentés" qu'il connaît personnellement avant d'appliquer une mise à jour avec un changement du numéro de version majeur.

Quant aux exemples de personnes qui ont été réellement confuses, notamment concernant les utilisateurs scientifiques de Python, j'en ai beaucoup: des collègues au travail, des personnes que je rencontre lors de conférences, des personnes qui demandent des conseils par e-mail, des étudiants dans mes classes. Cela commence généralement par "Je sais que vous êtes un expert Python, pouvez-vous m'aider à résoudre un problème?" Ce problème se révèle être un script qui fonctionne sur un ordinateur mais pas sur un autre. La plupart de ces personnes ne considèrent pas du tout les problèmes de dépendance, mais quelques-uns ont en fait comparé les numéros de version des deux installations, ne trouvant que de «petites différences».

Comme @ eric-wieser et @rgommers l'ont noté, ma demande est presque synonyme de demander que l'initiale "1" être supprimé des versions de NumPy. En d'autres termes, NumPy utilise déjà de facto le versionnage sémantique, même s'il n'est pas le résultat d'une décision politique et donc probablement pas fait de manière rigoureuse. Cependant, cela suggère que NumPy pourrait adopter le versionnage sémantique avec presque aucun changement du flux de travail de développement actuel.

Un commentaire d'un administrateur système m'a particulièrement frappé comme pertinent: il a dit que pour décider de la version à installer, toute convention autre que le versionnage sémantique est inutile.

Malheureusement, le versionnage sémantique est également inutile pour cela :-(. Je ne veux pas couper les cheveux ou exagérer; je comprends totalement que c'est un vrai problème. Mais ce n'est pas parce qu'un problème est réel qu'il a une solution. Vous ne pouvez fondamentalement pas résumer la question "Dois-je mettre à jour ce logiciel?" À une simple vérification mécanique. C'est un fantasme. Les projets qui utilisent semver font régulièrement des versions majeures que tous leurs utilisateurs devraient immédiatement mettre à niveau et apportent régulièrement des modifications majeures. communiqués.

Les administrateurs système ne peuvent ni explorer chaque package en détail (ils manquent de temps et de compétence) ni consulter tous leurs utilisateurs (trop nombreux). Ils doivent adopter une politique uniforme, ce qui tend à être basé sur l'hypothèse d'un versionnage sémantique. Par exemple, un administrateur d'un cluster informatique m'a dit qu'il vérifie avec quelques "utilisateurs expérimentés" qu'il connaît personnellement avant d'appliquer une mise à jour avec un changement du numéro de version majeur.

J'aime bien cette partie :-). Je doute que nous soyons d'accord sur la philosophie de semver, mais il est beaucoup plus facile d'avoir une discussion sur les effets concrets des différents schémas de versioning, et quel résultat nous trouvons le plus souhaitable.

Je ne pense pas que le concept de semver ait grand-chose à voir avec cette politique - est-ce que l'administrateur système à qui vous avez parlé vérifie réellement chaque projet pour voir s'il utilise semver? La plupart des projets ne le font pas, comme vous l'avez dit, il est même difficile de dire lesquels font. Et la politique est la même que celle utilisée par les administrateurs système bien avant que semver n'existe. Je pense qu'une meilleure caractérisation de cette politique serait: "suivre la recommandation du projet sur la prudence avec une mise à jour", avec la tradition ancienne que les versions majeures sont "grandes" et les versions mineures sont "petites".

La recommandation du projet NumPy est que les administrateurs système devraient passer à de nouvelles versions de fonctionnalités, donc ce que je retiens de cette anecdote est que notre schéma de numérotation actuel communique avec précision ce que nous voulons, et que le passage à semver ne le ferait pas ...

@njsmith OK, profit des aspects pratiques: quel est le rôle des numéros de version des logiciels dans la communication entre les développeurs de logiciels, les mainteneurs de systèmes et les utilisateurs de logiciels?

Là encore, il semble que nous ayons ici une divergence d'opinions majeure. Pour vous, ce sont les développeurs qui donnent des instructions aux responsables du système et aux utilisateurs, et utilisent les numéros de version pour transmettre leurs instructions. Pour moi, chaque joueur doit décider en fonction de ses critères, et le numéro de version doit servir de moyen de communication factuelle au niveau le plus grossier.

Étant donné que NumPy n'a aucune implication sur la sécurité, je ne vois pas comment et pourquoi le projet NumPy devrait donner des recommandations universelles. Les gens et les institutions ont des besoins différents. C'est pourquoi nous avons ArchLinux et CentOS, avec des politiques de mise à jour très différentes.

@khinsen Le oldnumeric fonctionne toujours parfaitement, et les gens peuvent l'installer avec:

pip install oldnumeric

Peut-être que cela pourrait être votre proposition de "numpy stable", où l'interface vers numpy est limitée à Python / Cython et rien n'est jamais changé. Bien sûr, écrire du code avec oldnumeric est très obscur, mais vous ne pouvez pas jouer sur les deux tableaux.

@xoviat C'est vrai, mais c'est un problème différent. Mon propos ici n'est pas la préservation des logiciels, mais la communication entre les différents acteurs de la gestion des logiciels.

Question: En tant qu'administrateur système (même uniquement sur votre ordinateur personnel), vous attendez-vous à ce qu'un package supprime une couche API complète de la version 1.8 à la version 1.9?

Pour ceux qui ont répondu «oui», deuxième question: pouvez-vous nommer un logiciel autre que numpy qui a déjà fait cela?

BTW, je peux vous assurer que beaucoup de gens ont été mordus par cela, car j'ai reçu beaucoup de courriers me demandant pourquoi MMTK a cessé de fonctionner du jour au lendemain. Tous ces gens avaient effectué des mises à jour de routine de leurs installations logicielles, sans s'attendre à des conséquences graves.

Mais abandonner oldnumeric n'était pas le pire événement de l'histoire récente de NumPy. Cet honneur va à la modification de la sémantique de copie / vue de certaines opérations telles que diagonal . Un code qui renvoie des résultats différents selon la version de NumPy (changement mineur de numéro de version!) Est un véritable cauchemar.

BTW, puisque presque personne ne connaît l'histoire: pip install oldnumeric fonctionne depuis il y a deux jours, car @xoviat a préparé ce module complémentaire et l'a mis sur PyPI. Merci beaucoup!

vous attendez-vous à ce qu'un package supprime une couche API complète de la version 1.8 à la version 1.9?

De quelle couche parlez-vous?

pouvez-vous nommer un logiciel autre que numpy qui a déjà fait cela?

SciPy a laissé tomber les packages weave et maxentropy , pandas casse régulièrement les principales fonctionnalités. Je suis sûr qu'il existe de nombreux autres exemples marquants. EDIT: Python lui-même par exemple, voir https://docs.python.org/3/whatsnew/3.6.html#removed

BTW, je peux vous assurer que beaucoup de gens ont été mordus par cela, car j'ai reçu beaucoup de courriers me demandant pourquoi MMTK a cessé de fonctionner du jour au lendemain. Tous ces gens avaient effectué des mises à jour de routine de leurs installations logicielles, sans s'attendre à des conséquences graves.

Ce changement a duré environ 10 ans, et il n'y a aucun moyen qu'un schéma de version différent aurait fait une différence ici.

L'abandon des fonctionnalités obsolètes est un compromis entre la rupture d'une petite fraction du code (ancien) et la facilité de maintenance de la base de code. Dans l'ensemble, si nous nous trompons, nous le faisons probablement du côté conservateur. En tant que personne qui a également dû faire face à de grandes bases de code d'entreprise vieilles de plusieurs années qui utilisent numpy, je ressens votre douleur, mais vous plaidez pour quelque chose qui n'est absolument pas une solution (et en général, il n'y a pas de solution complète; éduquer les utilisateurs sur des choses comme épingler des versions et vérifier les avertissements d'obsolescence est le mieux que nous puissions faire).

De quelle couche parlez-vous?

support numérique / numarray je suppose

@rgommers Désolé, j'aurais dû dire "un autre exemple en dehors de l'écosystème SciPy".

De plus, je ne me plains pas de l'abandon du support pour oldnumeric . Je me plains de faire cela sans changer le numéro de version majeure.

Quelle différence cela aurait-il fait? Cela aurait fait hésiter les gens à mettre à jour sans lire les notes de publication. Tout le monde utilisant (mais pas en développement) du code Python aurait pris cela comme un signe de prudence.

N'oubliez pas que l'écosystème SciPy compte un nombre énorme d'utilisateurs discrets qui ne suivent pas activement les développements. Python et NumPy sont des éléments d'infrastructure de même nature que ls et gcc pour eux. Et souvent, c'est moins que cela: ils utilisent des logiciels qui se trouvent être écrits en Python et qui dépendent de NumPy, et quand il se brise, ils sont complètement perdus.

@rgommers Désolé, j'aurais dû dire "un autre exemple en dehors de l'écosystème SciPy".

Je viens de modifier ma réponse avec un lien vers les notes de publication de Python, c'est en dehors de l'écosystème SciPy.

Quelle différence cela aurait-il fait? Cela aurait fait hésiter les gens à mettre à jour sans lire les notes de publication. Tout le monde utilisant (mais pas en développement) du code Python aurait pris cela comme un signe de prudence.

Ce ne sera tout simplement pas le cas. Si au lieu de 1.12, 1.13, 1.14, etc., nous avons 12.0, 13.0, 14.0, les utilisateurs s'y habituent et utiliseront la même stratégie de mise à niveau qu'auparavant. La grande majorité ne deviendra pas soudainement beaucoup plus conservatrice.

N'oubliez pas que l'écosystème SciPy compte un nombre énorme d'utilisateurs discrets qui ne suivent pas activement les développements. Python et NumPy sont des éléments d'infrastructure de même nature que ls et gcc pour eux. Et souvent, c'est moins que cela: ils utilisent des logiciels qui se trouvent être écrits en Python et qui dépendent de NumPy, et quand il se brise, ils sont complètement perdus.

Tout est vrai, et tous ne peuvent pas être réparés comme par magie par un numéro de version. S'ils ont exécuté pip install --upgrade numpy , ils doivent savoir ce qu'ils font (et de toute façon, ce n'est même pas un numéro de version). Si c'est leur système d'emballage, alors ils voient le problème du logiciel qui ne fonctionne pas sans suite de tests décente (ou qui n'a pas été exécuté).

Autres inconvénients de la modification du schéma de gestion des versions maintenant:

• nous ferions un changement dans la gestion des versions sans changement dans la politique de maintenance, sera déroutant plutôt qu'utile
• nous suivons maintenant fondamentalement l'exemple de Python et faisons la même chose que le reste de l'écosystème entier. C'est une bonne chose
• peut-être le plus important: nous perdrions la capacité de signaler des changements réellement importants. le genre pour lequel nous irions à 2.x, comme une version qui briserait l'ABI.

Ma référence de base n'est pas Python, mais une installation logicielle typique. Comme je l'ai dit, pour de nombreux utilisateurs (peut-être la plupart), NumPy est une infrastructure comme gnu-coreutils ou gcc. Ils n'interprètent pas les numéros de version spécifiquement dans le contexte de l'écosystème SciPy.

J'ai fait une vérification rapide sur un système Debian 9 avec environ 300 paquets installés. 85% d'entre eux ont un numéro de version commençant par un entier suivi d'un point. Les préfixes entiers les plus courants sont 1 (30%), 2 (26%), 0 (14%) et 3 (13%). Si NumPy adoptait un schéma de numérotation de version conforme aux attentes communes (ie versionnage sémantique ou une approximation proche), il se démarquerait définitivement et serait traité avec prudence.

Notez également que les seules mises à jour des logiciels installés par Debian qui ont jamais cassé les choses pour moi se trouvaient dans l'écosystème SciPy, à la seule exception d'une mise à jour d'Emacs qui a apporté des changements en mode organisation qui ont cassé une extension en mode org maison. Les préfixes de numéro de version globalement bas semblent donc indiquer que les logiciels les plus largement utilisés sont beaucoup plus stables que NumPy et ses amis.

L'uniformité à travers l'écosystème SciPy est en effet importante, mais je préférerais que l'ensemble de l'écosystème adopte un schéma de version conforme aux attentes du monde extérieur. Je commence simplement avec NumPy parce que je le vois comme la partie la plus élémentaire. C'est encore plus une infrastructure qu'autre chose.

Enfin, je considère un changement dans la sémantique d'une fonction comme un changement beaucoup plus important qu'un changement dans l'ABI. Le premier peut provoquer des cauchemars de débogage pour des centaines d'utilisateurs et faire en sorte que les programmes produisent des résultats erronés non détectés pendant des années. Ce dernier conduit à des messages d'erreur indiquant clairement la nécessité de réparer quelque chose.

Selon ces normes, NumPy ne suit même pas l'exemple de Python, car les seuls changements de sémantique dont je suis au courant dans le langage Python se sont produits de 2 à 3.

Enfin, je considère un changement dans la sémantique d'une fonction comme un changement beaucoup plus important qu'un changement dans l'ABI. Le premier peut provoquer des cauchemars de débogage pour des centaines d'utilisateurs et faire en sorte que les programmes produisent des résultats erronés non détectés pendant des années. Ce dernier conduit à des messages d'erreur indiquant clairement la nécessité de réparer quelque chose.

Nous essayons vraiment de ne pas le faire. Une casse claire lors de la suppression d'une fonction peut se produire, mais la modification silencieuse des résultats numériques ne devrait pas. C'est une chose que nous avons apprise du changement de vue diagonale - c'était une erreur avec le recul.

il se démarquerait certainement et serait traité avec prudence.

Je suis toujours en désaccord. Même sur Debian, qui n'est certainement pas "une installation logicielle typique" pour notre base d'utilisateurs (ce serait quelque chose comme Anaconda sous Windows). Vous semblez également ignorer mon argument ci-dessus selon lequel un utilisateur ne peut même pas voir un numéro de version normalement (ni avec pip install --upgrade ni avec un gestionnaire de paquets).

En outre, votre expérience selon laquelle tout le reste ne se rompt jamais est probablement due au fait que vous utilisez des éléments tels que des utilitaires de système d'exploitation et des programmes d'interface graphique, et non d'autres grandes chaînes de dépendances. Par exemple, l'ensemble de l'écosystème JavaScript / NodeJS est probablement plus fragile que celui de Python.

BTW, je peux vous assurer que beaucoup de gens ont été mordus par cela, car j'ai reçu beaucoup de mails me demandant pourquoi MMTK a cessé de fonctionner du jour au lendemain

Ceci est un bon exemple des subtilités ici. Autant que je sache, MMTK et vos autres projets sont les seuls encore existants qui ont été affectés par la suppression du code de compatibilité numeric / numarray. Combien d'utilisateurs estimez-vous avoir? 100? 1000? NumPy a des millions, alors peut-être que 0,1% de nos utilisateurs ont été affectés par cette suppression? Ce n'est certainement pas nul, et le fait qu'il soit petit ne signifie pas que cela n'a pas d'importance - j'aimerais que nous puissions soutenir 100% des utilisateurs pour toujours de toutes les manières. Et je comprends que c'est particulièrement pénible pour vous de recevoir 100% des plaintes de vos utilisateurs.

Mais si nous augmentons notre numéro de version majeur pour cela, cela signifie que pour 99,9% de nos utilisateurs, nous venons de pleurer au loup. C'est un faux positif. OTOH pour ces 0,1% d'utilisateurs, c'était vraiment important. Pourtant, il n'est pas rare que nous cassions plus de 0,1% des utilisateurs dans les versions

Il n'est tout simplement pas possible de communiquer ces nuances à travers l'instrument émoussé d'un numéro de version. Tout le monde veut un moyen rapide de savoir si une mise à niveau cassera son code, pour de bonnes raisons. Semver est populaire car il promet de le faire. Il est populaire pour la même raison qu'il est populaire de penser que les régimes à la mode peuvent guérir le cancer. Je souhaite que Semver ait également tenu ses promesses. Mais ce n'est pas le cas, et si nous voulons être de bons ingénieurs, nous devons faire face aux complexités de cette réalité.

Je ne vois pas comment et pourquoi le projet NumPy devrait donner des recommandations universelles. Les gens et les institutions ont des besoins différents.

Nous donnons des recommandations universelles parce que nous n'avons qu'un seul numéro de version, donc par définition, tout ce que nous en faisons est une recommandation universelle. Ce n'est pas quelque chose que nous contrôlons.

Cet honneur va au changement de la sémantique de copie / vue de certaines opérations telles que diagonal .

IIRC, nous n'avons littéralement pas reçu une seule plainte à ce sujet de la part de quelqu'un disant que cela avait enfreint leur code. (Peut-être une personne?) Je ne dis pas que cela signifie que personne n'a été affecté, de toute évidence, les personnes qui se plaignent d'un changement ne sont en général qu'une petite fraction de celles touchées, mais si vous utilisez les plaintes comme une approximation approximative du réel- impact mondial alors je ne pense pas que cela fasse le top 50.

Et BTW, je suis à peu près sûr que si vous cherchez à travers l'histoire profonde, vous pouvez trouver des changements beaucoup plus flagrants que cela :-).

Notez également que les seules mises à jour des logiciels installés par Debian qui ont jamais cassé les choses pour moi se trouvaient dans l'écosystème SciPy, à la seule exception d'une mise à jour d'Emacs qui a apporté des changements en mode organisation qui ont cassé une extension en mode org maison.

Respectueusement, je pense que cela en dit plus sur la façon dont vous utilisez NumPy contre Debian que sur NumPy contre Debian. J'adore Debian, je l'utilise depuis presque 20 ans maintenant, et je ne peux pas compter combien de fois c'est cassé. Rien que la semaine dernière, un problème bizarre avec le nouveau gnome a cassé mes scripts de connexion et une autre mise à jour a cassé mon trackpoint . (Les deux sont corrigés maintenant, mais quand même.) Je noterai également que l'emacs de Debian a été configuré pour télécharger et exécuter du code sur des canaux non chiffrés / non sécurisés pendant des années, en raison de problèmes de compatibilité ascendante concernant l'activation des contrôles de sécurité. Je ne pense pas qu'il y ait une telle chose comme une version de gcc qui ne brise pas quelques personnes, ne serait-ce que parce que les gens font des choses comme utiliser -Werror et ensuite des changements mineurs dans le comportement d'avertissement (qui peut s'appuyer sur des interactions entre les passes d'optimisation, etc.) deviennent des changements de rupture.

Les préfixes de numéro de version globalement bas semblent donc indiquer que les logiciels les plus largement utilisés sont beaucoup plus stables que NumPy et ses amis.

Les préfixes de numéros de version globalement bas sont dus au fait que les logiciels les plus largement utilisés n'utilisent pas semver.

Enfin, je considère un changement dans la sémantique d'une fonction comme un changement beaucoup plus important qu'un changement dans l'ABI. Le premier peut provoquer des cauchemars de débogage pour des centaines d'utilisateurs et faire en sorte que les programmes produisent des résultats erronés non détectés pendant des années. Ce dernier conduit à des messages d'erreur indiquant clairement la nécessité de réparer quelque chose.

Oui, c'est pourquoi nous sommes extrêmement méfiants face à de tels changements.

Il y a une certaine déconnexion dans les perspectives ici: vous semblez penser que nous changeons les choses bon gré mal gré tout le temps, que nous ne nous soucions pas de la compatibilité ascendante, etc. Je peux respecter cela; Je comprends que cela reflète votre expérience. Mais notre expérience est que nous accordons une extrême attention à de tels changements, et je dirais que lorsque je parle aux utilisateurs, c'est ~ 5% qui ont votre point de vue, et ~ 95% qui pensent que numpy fait soit un bon travail à la stabilité ou qu'il fait un trop bon travail et devrait être plus disposé à casser des choses. Peut-être pourrez-vous vous rassurer en sachant que même si nous vous décevons, nous décevons également ce dernier groupe :-).

à la seule exception d'une mise à jour Emacs

Eh bien, pour sortir du sujet, cela sert d'exemple de l'autre côté de la stabilité. Emacs est resté statique pendant des années en raison de la résistance de Stallman au changement, ce qui a abouti à la fourche xEmacs. Mon propre chemin est allé Emacs -> xEmacs, pour ne rien dire, -> Vim;) La fossilisation prématurée est aussi la raison pour laquelle j'ai arrêté d'utiliser Debian à l'époque. Pour certaines choses, le changement n'est tout simplement pas nécessaire ni même souhaité, et je pense que des gens exécutent d'anciennes versions de BSD sur du vieux matériel caché dans un placard. Mais je ne m'attends pas à ce qu'il y ait beaucoup de tels endroits.

A propos du problème actuel, je ne pense pas qu'un changement dans le schéma de version ferait vraiment une différence. Une voie plus productive pourrait être de résoudre le problème de la modernisation. @khinsen Voyez-vous comment accepter la mise à jour de vos principaux projets? Si tel est le cas, je pense que nous devrions explorer les moyens par lesquels nous pouvons vous aider à le faire.

J'essaye de mettre à jour les projets à
https://github.com/ScientificPython. Il nécessite la mise à jour du code Python qui
utilisé l'ancienne API C (et je veux dire ancienne; certaines fonctions telles que Py_PROTO étaient
à partir de 2000). Les RP sont bien sûr les bienvenus, mais je ne sais pas si quelqu'un
veut passer son temps là-dessus.

Le plus gros problème qu'il a soulevé je pense est qu'il y a "beaucoup
projets "(je ne sais pas où ils se trouvent exactement car tous les projets
que j'ai vu prendre en charge Python 3) qui ont également besoin d'être mis à jour; comment c'est
déterminé à quels projets le temps de développement de NumPy est-il alloué? Et aussi je
ne pense pas que sa revendication centrale était invalide: SciPy bénéficie grandement de la
fait qu'il pourrait simplement copier et coller d'anciens projets fortran (tels que
fftpack) avec peu ou pas de modification. Si ceux-ci avaient été écrits en disant
"fortran 2" et les nouveaux compilateurs ne compilaient que "fortan 3", il y aurait
ont été des problèmes importants.

Cela dit, ces problèmes ne sont pas vraiment la faute de NumPy. Malgré ce qu'il a
dit, avec NumPy 1.13 installé, oldnumeric a quand même réussi tous les tests,
indiquant que NumPy n'est pas le coupable ici. Puisque l'API oldnumeric est
littéralement plus d'une décennie (peut-être près de deux décennies!), et il
fonctionne sur le dernier NumPy, je pense que l'API NumPy est probablement stable
assez.

@charris Je suis entièrement d'accord avec vous que "ne jamais rien changer" n'est pas une attitude productive en informatique.

Mon point est que l'écosystème SciPy est devenu tellement populaire qu'aucune approche unique de gestion du changement ne peut convenir à tout le monde. Cela dépend de la rapidité avec laquelle les méthodes et leurs implémentations évoluent dans un domaine donné, des compétences techniques des praticiens, des autres logiciels dont ils dépendent, des ressources qu'ils peuvent investir dans le code, etc.

L'équipe de base actuelle de NumPy se soucie plus du progrès (dans une direction qui compte pour certains domaines mais qui n'est en grande partie pas pertinente pour d'autres) que de la stabilité. C'est bien - dans le monde Open Source, les personnes qui font le travail décident sur quoi elles veulent travailler. Cependant, j'ai l'impression qu'ils ne se rendent pas compte que beaucoup de personnes dont le travail dépend de NumPy ont des besoins différents, se sentent abandonnées par l'équipe de développement et commencent à s'éloigner de SciPy vers des technologies plus traditionnelles et plus stables telles que C et Fortran ( et, dans un cas, je sais, même à Matlab).

Je n'ai aucune idée du pourcentage d'utilisateurs de NumPy qui sont suffisamment mécontents de l'état actuel des choses, et je ne pense pas que quelqu'un d'autre l'ait. Une fois qu'un progiciel devient une infrastructure, vous ne pouvez pas facilement estimer qui en dépend. Beaucoup de ceux qui ne le savent même pas, et une grande partie du code qui dépend de NumPy (directement ou indirectement) n'est pas public et / ou n'est pas facilement détectable.

Si nous voulons que tout le monde soit heureux dans la communauté SciPy, nous devons trouver un moyen de répondre à des besoins divers. La toute première étape, à mon avis, consiste à transférer le contrôle du taux de changement dans une installation spécifique des développeurs vers une personne plus proche de l'utilisateur final. Cela pourrait être les utilisateurs finaux eux-mêmes, ou les administrateurs système, ou les conditionneurs, ou n'importe qui d'autre - encore une fois, je ne pense pas qu'il y ait une réponse universelle à cette question. Ce que cela exige des développeurs, ce sont des informations au bon niveau, et c'est pourquoi j'ai commencé ce fil. Bien sûr, les numéros de version ne peuvent pas sauver le monde, mais je les vois comme une première étape vers l'établissement d'une responsabilité distribuée pour la gestion du changement.

Enfin, certains d'entre vous semblent croire que je mène une bataille personnelle à propos de mon propre code. Vous serez peut-être surpris que mon attitude personnelle ne soit pas celle que je défends ici. Mon propre champ d'action pour le taux de changement se situe quelque part entre ce qui est commun dans mon domaine et ce qui semble être répandu dans l'équipe NumPy. La plupart de mes travaux utilisent aujourd'hui Python 3 et NumPy> 1.10. MMTK a 20 ans et je fais beaucoup de choses différemment aujourd'hui. Très souvent, je prends des morceaux de code de MMTK dont j'ai besoin pour un projet spécifique et je les adapte au "SciPy moderne", mais c'est quelque chose que je peux faire en toute confiance uniquement parce que j'ai écrit le code original.

J'ai maintenu un MMTK stable en tant que service à la communauté, pas pour mon propre usage, ce qui explique pourquoi j'ai effectué la maintenance de manière minimaliste, évitant des changements à grande échelle dans la base de code. Le financement des logiciels et des développeurs compétents dans le domaine est très difficile à trouver, de sorte que MMTK est toujours resté un projet à un seul mainteneur et contributeurs occasionnels. Je ne suis même pas sûr que le portage de la totalité de MMTK sur "SciPy moderne" ferait du bien à quiconque, car une grande partie du code qui dépend de MMTK n'est pas du tout maintenu. Mais alors, c'est vrai pour la plupart du code Python que je vois autour de moi, même du code sans aucun rapport avec MMTK. C'est la réalité d'un domaine de recherche où les expériences plutôt que le calcul et le codage sont au centre de l'attention.

@xoviat Le nombre de tests dans oldnumeric est ridiculement petit. Je ne conclurais pas grand-chose du fait qu'ils passent avec NumPy 1.13.

Les modules d'extension C que vous avez examinés ont littéralement 20 ans et ont été écrits pour Python 1.4. À l'époque, il faisait partie des exemples les plus sophistiqués de combos Python-C et a en fait façonné le développement précoce de Numeric (pré-NumPy) et même de CPython lui-même: les CObjects (pré-Capsules) ont été introduits en fonction des besoins de ScientificPython et MMTK .

Je suis le premier à dire que les API et les outils d'assistance actuels sont bien meilleurs et je pense qu'ils continueront de s'améliorer à l'avenir. Mais certaines personnes veulent simplement utiliser un logiciel pour faire de la recherche, aussi démodée soit-elle, et je pense qu'elles ont également le droit d'exister.

@rgommers Je

Si les gens autour utilisent principalement Anaconda sous Windows, cela confirme simplement que nous travaillons dans des environnements très différents. À l'ère de la diversité, j'espère que nous pouvons convenir que chaque communauté peut adopter les outils et les conventions qui fonctionnent bien pour elle.

Et oui, NodeJS est pire, je suis d'accord. Heureusement, je peux facilement l'ignorer.

Je viens de recevoir un e-mail d'un collègue qui suit ce fil mais n'oserait pas intervenir. Avec une excellente analogie:

"J'adore quand j'ai la chance d'acheter un nouveau microscope et de faire de meilleures sciences avec. Mais je détesterais voir quelqu'un remplacer mon microscope du jour au lendemain sans me consulter."

Il s'agit d'avoir le contrôle de ses outils.

Je promets que je ne ferai jamais irruption dans le laboratoire de votre collègue au milieu de la nuit pour améliorer leur engourdissement. Je n'ai même pas de cagoule .

Les personnes qui décident des mises à jour (qui ne sont pas toujours des utilisateurs finaux) le voient. Ils ne font pas que "pip install --upgrade" une fois par semaine. Ils considéreraient même cela comme une attitude insouciante.

S'ils sont administrateurs système et comprennent les avantages et les inconvénients de diverses méthodes d'installation, ils devraient également comprendre (ou apprendre) comment fonctionne le contrôle de version dans le monde Python (et de nombreux autres projets logiciels qui n'utilisent pas non plus de semver strict).

L'équipe de base actuelle de NumPy se soucie plus du progrès (dans une direction qui compte pour certains domaines mais qui n'est en grande partie pas pertinente pour d'autres) que de la stabilité.

Je suis désolé, mais cela montre simplement que vous n'avez pas du tout suivi le développement de NumPy ces dernières années, ou que vous avez un ensemble de lunettes très particulier. NumPy est en fait un projet très difficile auquel contribuer, car il y a beaucoup de souci de compatibilité ascendante. C'est l'une des principales raisons pour lesquelles nous avons du mal à attirer de nouveaux responsables.

et, dans un cas, je sais, même à Matlab

Matlab était connu pour avoir rompu la compatibilité. La première chose que les projets coopératifs utilisant Matlab ont fait a été de spécifier la version que tout le monde devait utiliser, de même avec Microsoft Word s'il était utilisé pour la documentation. Je connais des gens qui sont passés à NumPy précisément pour améliorer la compatibilité. Matlab a ses vertus, mais la compatibilité n'en fait pas / n'en faisait pas partie. Peut-être que les choses ont changé?

Cependant, je pense que nous pouvons faire plusieurs choses à l'avenir qui pourraient contribuer à la compatibilité. Le premier est lié à la discussion actuelle sur les NEP. Maintenant que NumPy est plus mature, il pourrait être judicieux d'utiliser davantage les NEP lorsque des modifications affectant la compatibilité sont proposées, en particulier si les NEP sont plus publics et consultables. Deuxièmement, nous pourrions essayer de mettre en place des roues pour les anciennes versions de NumPy sur PyPI si ce n'est pas trop de travail. L'utilisation d'environnements virtuels semble être la meilleure idée actuelle pour obtenir la reproductibilité, et avoir un plus grand choix de roues à télécharger pourrait aider à cela.

Deuxièmement, nous pourrions essayer de mettre en place des roues pour les anciennes versions de NumPy sur PyPI si ce n'est pas trop de travail.

Grâce aux efforts de @ matthew-brett, il semble que l'état actuel est que nous avons les roues Windows de retour à 1.10 , MacOS à 1.5 (sauf 1.7 est manquant ) et Linux à 1.6 .

La situation MacOS / Linux semble assez raisonnable. Je suppose que nous pourrions remplir plus de versions de Windows? OTOH pip install sous Windows n'a jamais fonctionné sans efforts héroïques, donc je ne suis pas sûr qu'il y ait un large public pour cela. Nous avons déjà 2 ans et cela augmentera avec le temps.

De plus, la dernière fois que nous avons téléchargé de vieilles roues, quelqu'un s'est fâché contre nous parce que leur flux de travail supposait qu'il n'y avait pas de roues et que la rétrocompatibilité pour eux était rompue :-)

J'adorerais entendre cette histoire.

Non pas que je connaisse vraiment bien ce genre de choses, mais je suppose que nous pouvons essayer d'améliorer les choses (je ne suis pas tout à fait sûr de ce que cela signifie!), Le fait est que nous devons avancer lentement et à l'exception peut-être de certaines erreurs, toutes les versions étaient destiné à briser le code de très peu de gens. Je pense que notre version mineure signifie "presque tout le monde devrait mettre à jour et être capable de mettre à jour sans rien remarquer", et je crois franchement que c'est vrai. (Évidemment, il y a des choses qui ont affecté beaucoup de gens comme les dépréciations entières, mais elles ne créent pas de mauvais résultats et ont été longues à faire)

Je peux voir qu'il y a peut-être eu des changements suffisamment importants pour justifier l'incrémentation de la version majeure, bien que je ne sois franchement pas sûr de celui qui serait. Et oui, il y a peut-être une perte d'élan historique en ce qui concerne les versions majeures.

En tout cas, je ne peux pas non plus dire que je suis fan de dire que (presque) chaque version est une version majeure. Je comprends que nous avons peut-être énervé les gens avec certains changements, mais j'ai pris part à des changements assez importants et à chaque fois après avoir expliqué les raisons, j'ai seulement entendu dire que c'était la bonne chose à faire, et nous avons également attendu années jusqu'à ce que ces changements prennent effet.

En ce qui concerne gcc, etc. Par exemple, je ne connais pas grand chose à la compilation / C ++, j'ai été ennuyé par gcc 4.8 ou alors commençant à me forcer à comprendre comment changer correctement les indicateurs à cause de certaines fonctionnalités de C ++ 11 ou donc attendu, ce qui provoque des réactions très similaires aux e-mails que vous semblez recevoir à propos de numpy, donc je ne suis pas sûr que ce soit très différent :).

Quoi qu'il en soit, je ne veux pas trop discuter ici, j'apprécie les commentaires sur la question de savoir si nous pouvons être trop rapides ou pas assez prudents, mais je dois admettre que je ne vois pas non plus tout à fait que changer la version majeure aidera beaucoup avec cette. Personnellement, je pense que 1.13 et 1.6 sont au moins une version majeure à part dans un certain sens, mais il n'y a pas une seule version entre les deux que je puisse indiquer et dire: c'était une rupture de compatibilité majeure pour de nombreux utilisateurs.
Je me souviens avoir lu des commentaires dans le code: "Faisons ça dans Numpy 2 peut-être", exactement à cause de la peur de toute rupture, avec cette approche, je crains que numpy aurait beaucoup calé, et franchement je suis un peu fier d'en faire partie de ce qui me paraissait au moins une phase plus active qui était nécessaire et qui aurait été difficile si nous étions encore plus conservateurs. (Je suis probablement biaisé car je n'ai pas vraiment la moindre idée de ce qui s'est passé avant de venir :)).

Désolé, peut-être que cela n'a pas de sens (nous venons d'avoir une fête de Noël). La proposition semver a du sens, mais je dois admettre qu'elle ne semble pas être une vraie solution. Je peux être d'accord pour essayer d'incrémenter la version majeure de manière plus agressive, mais je suis également en désaccord avec le fait d'appeler fondamentalement chaque version une version majeure. Je peux également être d'accord pour essayer d'être plus conservateur dans certains cas, mais je ne suis franchement pas tout à fait sûr de ce que sont ceux-ci (il suffit de compter le nombre de PR suspendus, car personne ne sait si cela pourrait briser la compatibilité quelque part;), je suis sûr que est une bonne portion)?

Et même si j'ai lu des plaintes, si vous apportez un peu de bug et d'insistance, ce n'est pas comme si nous n'annulerions pas chaque changement si cela est raisonnablement possible ou du moins le retarderons d'un an ou plus. Je dirais que cela explique en partie pourquoi nous avons choisi un modèle de gouvernance conservateur….

Donc, après avoir babillé pendant un si long moment:

• "Presque aucun code n'est cassé" semble peut-être OK pour une version mineure?
• Nous devons avancer lentement?
• Les choses finiront par casser, et peut-être pourrions-nous parfois incrémenter une version majeure. Peut-être même essayer de changer de type FutureWarning dans les versions majeures. (Je ne crois franchement pas que cela aidera, mais je suis prêt à essayer)

Plus important encore: je connais la frustration, mais y a-t-il une vraie solution pour nous? Pensez-vous que si nous incrémentons la version majeure de manière agressive, vous recevrez moins d'e-mails?

@xoviat demandez -vous l'histoire sur l'obtention de plaintes pour le téléchargement de roues pour les anciennes versions? C'était # 7570.

Ma définition préférée de semver (que je ne trouve plus de lien vers la publication d'origine):

• majeur: nous avons brisé le code utilisateur exprès
• mineur: nous avons cassé le code utilisateur par accident
• patch: nous avons cassé les solutions de contournement des utilisateurs aux bogues de la dernière version mineure

ce qui est un peu effronté, mais je pense que cela touche un élément important, _tout changement de comportement_ va briser un utilisateur quelque part. Cela est particulièrement vrai avec les projets qui ont de grandes surfaces d'API.

La toute première étape, à mon avis, consiste à transférer le contrôle du taux de changement dans une installation spécifique des développeurs vers une personne plus proche de l'utilisateur final.

Je pense que quelque chose qui manque dans cette conversation est que les anciennes versions des bibliothèques sont toujours disponibles (sur pypi à partir de la source) donc si vous avez du code qui nécessite une ancienne version de python / numpy / matplotlib, utilisez les anciennes versions. Les environnements d'espace utilisateur ne rendent pas cela trop difficile à gérer.

Si vous souhaitez utiliser de nouvelles versions des bibliothèques, vous devez payer le coût de suivre les changements. Pour pousser sur l'analogie du microscope, vous devez faire un entretien de routine sur votre microscope ou il se dégrade avec le temps; le logiciel n'est pas différent.

@njsmith C'est assez drôle. IMO # 7570 n'est pas un problème valide étant donné que
NumPy était conforme aux spécifications de la roue manylinux. Généralement, les roues
devrait être téléchargé pour les anciennes versions, en supposant que le temps soit libre. Donné
ce temps n'est pas gratuit, on pourrait simplement noter que les gens peuvent construire des roues
pour une version spécifique de NumPy s'ils le souhaitent; soumettre un PR au
référentiel numpy-roues. Ou pas.

@xoviat Je veux dire, si leur système

@njsmith Votre rôle dans l'analogie des microscopes est celui d'un vendeur de microscopes qui aborde le directeur de laboratoire de mon collègue avec une offre de remplacement de tous les microscopes du laboratoire par son dernier modèle, cachant la phrase "incompatible avec des échantillons de plus de 1 mm d'épaisseur" en petits caractères du contrat. Cela rend très difficile pour le directeur du laboratoire de comprendre qu'il y a un point technique qui doit être discuté avec les personnes qui comprennent ces détails.

@rgommers Je comprends que maintenir NumPy est une corvée, et en fait, je gérerais les changements différemment, principalement pour cette raison si j'étais en charge. Je mettrais le code actuel en mode de maintenance minimale et commencerais une refonte majeure dans un espace de noms différent, laissant l'ancien et le nouveau coexister indéfiniment avec l'interopérabilité via l'interface de tampon. Et oui, je sais que ce n'est pas une entreprise anodine pour de nombreuses raisons, mais je pense que c'est le seul moyen de sortir de la pile de dettes techniques accumulées. Le principal objectif de la refonte serait la maintenabilité.

D'un autre côté, j'avoue certainement avoir un ensemble de lunettes très particulier, mais c'est vrai pour tout le monde dans cette discussion. Mes lunettes sont celles de "l'informatique scientifique traditionnelle", qui est mon environnement de travail. La ligne de base (attente par défaut) est que les mises à jour ne cassent jamais rien intentionnellement. C'est la politique des langages standardisés (C, Fortran) mais aussi des bibliothèques d'infrastructure (BLAS, LAPACK, MPI, ...). L'innovation se produit néanmoins (par exemple ATLAS). Si vous pensez que c'est conservateur, laissez-moi décrire ce que signifie conservateur dans mon monde: n'installez jamais une version de quoi que ce soit qui n'a pas au moins deux ans, pour être sûr que la plupart des bogues sont connus. C'est une politique courante pour les supercalculateurs dont le temps coûte très cher et dont les résultats peuvent difficilement être vérifiés pour cette raison.

Notez que je ne dis pas que NumPy devrait adopter les attentes par défaut de mon monde. Je dis simplement que cela devrait indiquer clairement que c'est différent.

@seberg "Presque aucun code n'est cassé" semble bien en théorie pour une version mineure. Mais une fois qu'un logiciel acquiert le statut d'infrastructure (et à mon avis, NumPy est à ce niveau), il est impossible d'estimer le nombre de développeurs et d'utilisateurs qui pourraient être affectés. Le critère devient alors invariablement "quasiment personne à qui je pense n'est affecté", et ce n'est pas un bon critère.

@tacaswell Je pense que la différence entre "exprès" et "par accident" compte beaucoup dans la pratique. Cela affecte l'attitude de chacun face à un changement. Regardez simplement d'autres aspects de la vie. Si la distinction n'avait pas d'importance, nous pourrions supprimer le mot «attention» de la langue anglaise.

Eh bien, franchement, je pense que l'idée de «réaménagement majeur» est à peu près abandonnée en ce moment car elle exigerait soit beaucoup plus de puissance de développement et pourrait créer un autre type de désordre (voir py2 et py3 pour les premières années)?

D'accord, numpy est une infrastructure, mais je ne suis pas fan de simplement agir comme si casser le code d'un plus grand nombre de personnes était OK / l'intention en augmentant plus rapidement les versions majeures est une solution. Cela ressemble plus à abandonner la tâche de faire de notre mieux pour faire des versions "presque aucun code n'est cassé" (peut-être avec l'exception "sauf si vous n'avez pas regardé les avertissements pour quelques versions"), alors aider réellement à la décision de mise à jour.

Donc, parfois, nous devrions probablement reconnaître que ce n'est peut-être pas vrai, mais sinon, je préférerais de loin obtenir des solutions pour nous assurer que nous ne cassons plus. Bien sûr, vous avez proposé une solution (être très très conservateur et commencer numpy 2 avec une refonte majeure), mais une fois que nous admettons que cette solution n'est tout simplement pas réalisable sans un financement majeur, que pouvons-nous faire d'autre?

Ou laissez-moi être clair: si vous connaissez quelqu'un capable de suivre les développeurs numpy qui peut garder un œil sur le fait d'être plus conservateur lorsque cela est nécessaire, vous savez que j'apprécie au moins cela. Mais personnellement, je n'apprécie pas d'abandonner nos progrès consistant à nous débarrasser au moins lentement de certains des coins les plus sombres de Numpy pour permettre un développement futur. Au mieux, nous nous retrouverions avec un NumPy mort et un remplaçant dans quelques années, au pire, nous finirions par être dépassés et en aval frustrés de ne pas pouvoir avancer et peut-être que des «remplaçants» surgiraient, qui par nature si vous n'êtes pas aussi mature, cela ne fait qu'empirer les choses.

Je suis d'accord avec @seberg sur la création d'un espace de noms différent. le
toute l'hypothèse derrière cette idée est que le projet NumPy a un nombre illimité
talent et ressources pour maintenir une bibliothèque qui fonctionne pour tout le monde.
Cependant, ce n'est pas le cas. Les développeurs ne sont pas parfaits, ils
se tromper la première fois. Les personnes qui écrivent le code numérique original
ne pouvait pas prédire tous les scénarios dans lesquels il serait utilisé, et ils
ne pouvait pas prédire la montée des implémentations alternatives, telles que PyPy.

Je pense que la stabilité de l'API est très importante. Je pense aussi que NumPy a
généralement bien compris. Le fait est que NumPy est déjà
difficile à raisonner (et cela devrait être, étant donné que chaque dernière once de
les performances sont importantes), mais créer un espace de noms différent le rendrait
extrêmement difficile de garder toutes les implications du changement de code dans
ta tête. Je pense qu'il est fort probable que si NumPy faisait cela, il y aurait
être beaucoup plus de bogues parce que les développeurs ne comprennent pas le
ramifications du changement de code dans une interface sur l'autre.

En résumé, je comprends parfaitement les frustrations des gens. Mais comme @njsmith
dit, il n'y a aucune solution au problème qui satisfera chaque utilisateur.
Il n'y a que des solutions qui satisferont la plupart des utilisateurs la plupart du temps. Et
la réalité est que si NumPy s'adressait à la minorité d'utilisateurs (pas
de manière péjorative) qui exigeait la stabilité de l'API par-dessus tout, le
Le financement de NUMFOCUS pourrait se tarir parce que le montant de l'argent ne serait pas clair
a été utilisé pour, et alors où serions-nous? Probablement dans une situation où
MMTK ne peut plus dépendre de NumPy, tout comme la situation où il pourrait
ne dépendent plus de Numeric.

Je mettrais le code actuel en mode de maintenance minimale et commencerais une refonte majeure dans un espace de noms différent, laissant l'ancien et le nouveau coexister indéfiniment avec l'interopérabilité via l'interface de tampon. Et oui, je sais que ce n'est pas une entreprise anodine pour de nombreuses raisons, mais je pense que c'est le seul moyen de sortir de la pile de dettes techniques accumulées. Le principal objectif de la refonte serait la maintenabilité.

Je suis en fait d'accord avec vous, mais je ne vois pas comment c'est faisable sans une injection majeure de financement / vision. NumPy constitue un énorme corpus de travail. Peut-être que @teoliphant et @skrah réussiront avec plaisir , mais ce sera une bataille difficile.

Compte tenu du NumPy que nous avons aujourd'hui, je pense que nous faisons aussi bien que nous pouvons raisonnablement le faire.

Pour ceux qui ont répondu «oui», deuxième question: pouvez-vous nommer un logiciel autre que numpy qui a déjà fait cela?

django est un autre logiciel notable qui n'utilise pas le versionnage sémantique. Ils utilisent des modifications majeures pour indiquer des pauses substantielles, mais rendent obsolètes les éléments des modifications .x après une longue période d'avertissements. Plus ou moins comme NumPy.

Je suis vraiment d'accord avec toi,

@shoyer par intérêt, pourquoi? Comment cela ne se transformerait-il pas en une transition très douloureuse de type py3k vers la nouvelle base de code à un moment donné?

C'est la politique des langages standardisés (C, Fortran) mais aussi des bibliothèques d'infrastructure (BLAS, LAPACK, MPI, ...). L'innovation se produit néanmoins (par exemple ATLAS).

L'innovation au rythme de LAPACK / ATLAS / OpenBLAS est une recette pour que NumPy devienne inutile beaucoup plus rapidement qu'elle ne le ferait autrement.

Ecoutez, il doit être clair pour vous d'après toutes les réponses que ce changement de version ne va pas se produire, et c'est le consensus entre les ~ 7 développeurs de base actifs et certains développeurs de grands projets en aval. Si vous avez besoin d'une stabilité absolue, il vaut probablement mieux épingler une version fixe sur vos systèmes pendant quelques années et éduquer vos administrateurs système à ce sujet.

Comment cela ne se transformerait-il pas en une transition très douloureuse de type py3k vers la nouvelle base de code à un moment donné?

La grande différence est que si Python 3 est un commutateur tout / rien (pour les programmes Python), il est facile ou du moins faisable de mélanger / assortir différentes bibliothèques ndarray. L'interface tampon signifie que vous pouvez transférer des données dans les deux sens sans copie. Si vous forcez les entrées à vos fonctions avec np.asarray() vous ne remarquerez peut-être même pas si une bibliothèque avec laquelle vous travaillez avec des commutateurs pour renvoyer des tableaux d'un type différent.

Cela ressemble à la répétition de parties de numeric / numarray / numpy
expérience, qui n'était pas non plus très agréable (l'interface du tampon
aide, mais je pense qu'une telle transition impliquera toujours du code manuel
changements, qui ne sont pas tous triviaux). Ce ne sera pas non plus possible
pour les bibliothèques telles que Scipy de "mettre à niveau" vers le "nouveau tableau" sans
rupture de la compatibilité descendante, de sorte que le problème ne fait que remonter
l'écosystème, obligeant les autres bibliothèques à prendre une décision similaire
abandonner les anciens espaces de noms.

Si tout le monde contraignait ses entrées avec np.asarray , alors np.matrix ne serait pas un problème :-).

Si différentes bibliothèques de tableaux peuvent s'entendre sur les types de canard et que nous nous limitons aux dtypes représentables par le protocole de tampon, alors cela peut fonctionner. Mais si le but d'une réécriture était de faire des changements d'interface incompatibles sur les objets du tableau et d'implémenter de nouveaux dtypes, ... je ne vois vraiment pas comment le faire fonctionner. Exemple concret: une chose évidente à corriger dans ce type de réécriture serait le comportement de ndarray.dot sur les entrées de grande dimension. Mais s'il y a une bibliothèque là-bas qui fait def f(a, b): a.dot(b) , alors la création d'une telle bibliothèque la cassera potentiellement. Peu importe que cette bibliothèque s'appelle numpy ou non.

Et c'est avant même d'entrer dans l'impossibilité générale de tout réécrire en un seul big bang, en soutenant l'attention des développeurs pendant que nous faisons cela, et non seulement en faisant les choses correctement, mais en faisant tellement mieux que cela peut convaincre les gens de migrer - le tout sans aucun rétroaction incrémentielle des utilisateurs. Je pense que dynd est un exemple instructif ici.

@rgommers Veuillez relire ce que j'ai écrit: Je ne propose pas, répète pas , que NumPy adopte le rythme de LAPACK. Je propose qu'il signale clairement aux personnes qui ont une telle attente (c'est-à-dire 80% des personnes de mon environnement) que ce n'est pas le cas.

@njsmith Un aspect majeur d'une refonte, à mon avis, serait d'abandonner OO. Ce n'est pas une bonne approche pour structurer le code pour une seule structure de données avec des tonnes de fonctions qui fonctionnent dessus. Écrivez np.dot(a, b) et le problème que vous décrivez s'évapore instantanément. Vous pouvez avoir n'importe quel nombre d'implémentations de namespace.dot vous aimez. Chaque bibliothèque peut utiliser celle qu'elle aime, et elle peut toujours interagir. C'est OO qui crée un espace de noms unique pour les méthodes, et c'est un problème.

Oui, c'est une rupture majeure avec les habitudes Python. Et oui, il sera difficile d'implémenter des opérateurs en plus de cela. Mais je pense que cela peut être fait, et je pense que cela en vaut la peine.

Juste pour montrer que je peux être en faveur de casser des choses ;-)

@rgommers Veuillez relire ce que j'ai écrit: je ne propose pas, répétez pas, que NumPy adopte le rythme de LAPACK.

Je comprends que. Les deux paragraphes de ma réponse n'étaient pas directement liés, désolé si cela prêtait à confusion.

Je propose qu'il signale clairement aux personnes qui ont une telle attente (c'est-à-dire 80% des personnes de mon environnement) que ce n'est pas le cas.

C'est ce que je disais, le consensus semble être que votre proposition sera rejetée. Vous allez devoir simplement demander une version épinglée à ces 80% et expliquer pourquoi c'est ce que vous voulez.

@khinsen OK, alors faites comme si mon exemple était les changements incompatibles d'indexation que nous ferions sûrement si c'était possible. (L'indexation sophistiquée a des cas d'angle extrêmement déroutants.)

@njsmith Même problème, d'une certaine manière. L'indexation est un appel de méthode en Python, donc c'est à nouveau OO.

Remarque latérale: l'indexation sophistiquée est la plus grande erreur de conception dans NumPy, à mon avis, car elle n'a même pas (et n'a jamais eu) de spécification sans ambiguïté. Il fait np.take pour les arguments entiers et np.repeat pour les arguments booléens. Puisque les booléens sont un sous-type d'entiers en Python, cela crée une ambiguïté pour les arguments contenant uniquement des 0 et des 1.

Il y a en fait une relation avec le sujet de ce fil, car c'est exactement le genre d'erreur de conception qui se produit lorsque le développement avance trop vite.

Je parle de l'indexation sophistiquée dans mes cours SciPy exclusivement pour dire aux gens de ne pas l'utiliser. Il y a np.take et np.repeat qui fonctionnent parfaitement et ne causent aucun problème. Et si vous les utilisez comme des fonctions plutôt que comme des méthodes, il n'y a pas non plus de problème OO. Pour ceux qui n'aiment pas np.repeat parce que le nom ne suggère pas l'intention lorsqu'il est utilisé avec des booléens, introduisez simplement un alias: select = np.repeat . Encore une fois quelque chose rendu inutilement difficile par OO.

Notez également que l'indexation simple n'est pas sujette à un tel problème. Il fait ce à peu près tout le monde s'attend à ce qu'il fasse dans toutes les circonstances possibles, de sorte qu'il peut être implémenté dans une méthode.

La question épineuse de mon point de vue est l'arithmétique. Vous voulez écrire a+b pour l'ajout de tableau, plutôt que np.add(a, b) , mais il n'y a pas d'accord universel sur ce que doit faire exactement a+b , en particulier en termes de résultat dtype . C'était l'un des problèmes fondamentaux de la division Numeric / numarray, qui a conduit à l'introduction de nouveaux types scalaires dans NumPy, et ceux-ci provoquent également leur part de surprises désagréables. Je crois que ce problème peut être résolu, mais pas dans des remarques parallèles sur une discussion sur un problème GitHub.

@rgommers Si «demander une version épinglée à 80%» était possible, je l'aurais fait il y a longtemps. «That 80%» n'est pas une communauté organisée à laquelle vous pouvez parler. C'est un grand nombre de personnes qui partagent une culture de fond, mais n'interagissent pas les unes avec les autres. Votre suggestion est un peu comme "demander aux utilisateurs de Windows de passer à Linux" (ou vice versa).

C'est le point que j'essaie de faire valoir en insistant sur le fait que NumPy est un logiciel d'infrastructure. Pour beaucoup de gens, ce n'est qu'une des centaines de briques lego qui composent l'installation de leur logiciel. Ils ne s'en soucient pas spécifiquement, il a juste besoin d'être là et de "travailler".

Je ne veux pas trop faire dérailler cela, mais je n'ai aucune idée de ce à quoi vous faites référence avec les tableaux np.repeat et bool

@ eric-wieser répète 0 fois et vous le supprimez du tableau, 1 fois et il reste. Je ne suis pas d'accord pour enseigner cela au lieu d'indexer, mais peu importe (la pire étrangeté a disparu de nos jours, donc oui dans numpy un bool n'est pas un int dans la plupart des cas, en acceptant cela, vous allez bien maintenant je pense, donc c'est même une incompatibilité avec listes si vous souhaitez le voir comme ça, mais ...).

Un point secondaire, car cela ne va plus nulle part de toute façon :). J'espère en fait un peu que le fait de réparer lentement des trucs dans numpy rendra plus facile à un moment donné dans le futur numpy plus remplaçable.

Votre suggestion est un peu comme "demander aux utilisateurs de Windows de passer à Linux" (ou vice versa).

Hmm, demander aux gens qui sont techniquement compétents (je l' espère ...) pour savoir comment les numéros de version dans le monde réel travail est en réalité pas vraiment quoi que ce soit comme un interrupteur Windows à Linux.

C'est le point que j'essaie de faire valoir en insistant sur le fait que NumPy est un logiciel d'infrastructure.

Et probablement, si nous voulions faire ce changement, vous passerez à SciPy parce que c'est la prochaine infrastructure? Quand cesse-t-il d'être une infrastructure? Et pourquoi NumPy et les autres éléments de l'infrastructure voudraient-ils avoir un schéma de version complètement différent de Python lui-même et du reste de tout l'écosystème scientifique Python?

Ce 80% "n'est pas une communauté organisée à qui vous pouvez parler.

Les administrateurs du ou des supercalculateurs que vous utilisez devraient vraiment se parler, n'est-ce pas? Il ne peut y avoir des masses de gens qui courent autour de tous les logiciels de mise à jour sur ces deux systèmes sans jamais parler. Je ne voulais pas dire que vous devriez éduquer 80% de tous les administrateurs système dans le monde, juste ceux dont vous avez besoin.

@seberg Déclarer que les listes et les tableaux sont des types de données différents qui ne partagent l'indexation qu'en tant que propriété commune est un point de vue valide à adopter. Cela faciliterait également l'explication de l'existence de scalaires NumPy spécifiques. Mais je n'ai vu aucune présentation de NumPy qui prend ce point de vue.

@rgommers

Les administrateurs du ou des supercalculateurs que vous utilisez devraient vraiment se parler, n'est-ce pas?

Non. Ils ne connaissent même pas l'existence des autres. Ils travaillent pour différentes organisations dans différents endroits, dont le seul point commun est d'avoir quelques utilisateurs en commun.

Je ne voulais pas dire que vous devriez éduquer 80% de tous les administrateurs système dans le monde, juste ceux dont vous avez besoin.

Ce n'est pas à propos de moi - j'ai une solution qui fonctionne parfaitement pour moi: j'installe toujours Python ainsi que toutes les bibliothèques à partir des sources, dans mon répertoire personnel.

Il s'agit de personnes avec lesquelles je collabore et de personnes qui me demandent de l'aide (par exemple parce qu'elles ont participé à l'un de mes cours Python dans le passé). Ils n'ont pas la compétence technique pour gérer leur propre installation Python et s'en remettre à quelqu'un d'autre (administrateur ou collègue plus expérimenté).

pour apprendre comment les numéros de version dans le monde réel fonctionnent réellement

Dans la culture d'arrière-plan partagée des personnes auxquelles je pense, le monde réel fonctionne en fait comme le versionnage sémantique, ou une approximation étroite.

Dans la culture d'arrière-plan partagée des personnes auxquelles je pense, le monde réel fonctionne en fait comme le versionnage sémantique ou une approximation étroite.

C'est alors parce qu'ils utilisent un nombre limité de bibliothèques, principalement lentes comme LAPACK & co. Comme @njsmith l'a souligné, la majorité des logiciels ont des numéros de version faibles car ils n'utilisent pas le contrôle de version sémantique.

@rgommers Ils utilisent principalement des bibliothèques lentes, même si je ne dirais pas "un petit nombre".

Comme @njsmith l'a souligné, la majorité des logiciels ont des numéros de version faibles car ils n'utilisent pas le contrôle de version sémantique.

Pas dans mon expérience. Mais alors, «majorité» signifie probablement «la plupart de ceux que je connais», tant pour vous que pour moi, et il y a probablement peu de chevauchement entre les paquets que vous utilisez et les paquets que j'utilise, en dehors de l'écosystème SciPy.

Et probablement, si nous voulions faire ce changement, vous passerez à SciPy parce que c'est la prochaine infrastructure? Quand cesse-t-il d'être une infrastructure?

Je préférerais en effet que SciPy et tous les autres principes fondamentaux de l'écosystème SciPy adoptent les mêmes principes, mais personnellement, je n'investirai aucun effort pour défendre cela ailleurs que pour NumPy, qui est beaucoup plus largement utilisé que n'importe lequel des les autres bibliothèques, et aussi beaucoup plus fondamentales. Les tableaux NumPy sont la structure de données centrale de nombreux logiciels scientifiques, tandis que SciPy n'est qu'un énorme ensemble de fonctions à partir desquelles une application donnée utilise un petit sous-ensemble.

Notez également que SciPy utilise de facto le contrôle de version sémantique, mais probablement pas intentionnellement, car il vient juste d'atteindre 1.0.

Et pourquoi NumPy et les autres éléments de l'infrastructure voudraient-ils avoir un schéma de version complètement différent de Python lui-même et du reste de tout l'écosystème scientifique Python?

L'ensemble de l'écosystème SciPy devrait en effet utiliser la même approche, celle qui est (à mon sens) la dominante en informatique scientifique. Cela ne s'applique pas aux bibliothèques Python et Python d'autres domaines, qui ont des habitudes différentes. Le développement Web, par exemple, est beaucoup moins conservateur que l'informatique scientifique. Il est également principalement effectué par différentes personnes, qui s'occupent de différents utilisateurs. Le langage Python serait le seul point de contact.

Les tableaux NumPy sont la structure de données centrale de nombreux logiciels scientifiques, tandis que SciPy n'est qu'un énorme ensemble de fonctions à partir desquelles une application donnée utilise un petit sous-ensemble.

Et la structure centrale des données est stable. La grande majorité des changements incompatibles dans une version donnée sont des cas secondaires et généralement pas dans le comportement ndarray. Voir https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes par exemple. Notez également qu'aucun de ces changements n'aurait de sens pour un administrateur système, donc même s'ils regardaient ces notes pendant longtemps (si cela avait été 2.0.0), ils ne seraient pas en mesure de décider si une mise à jour était correcte ou ne pas.

Notez également que SciPy utilise de facto le contrôle de version sémantique, mais probablement pas intentionnellement, car il vient juste d'atteindre 1.0.

SciPy utilise exactement le même schéma de version et la même politique de dépréciation / suppression que NumPy. Être à 0.x pendant une longue période n'implique pas semver.

celui qui est (selon moi) le dominant en informatique scientifique

Les comparaisons traditionnelles de l'écosystème SciPy sont avec des choses comme Matlab et R. Je ne trouve aucune information sur R, mais il est à 3.x et a beaucoup évolué, donc probablement pas semver. Matlab: certainement pas semver.

RE: indexation sophistiquée. En effet, cela pourrait utiliser une fonction dédiée. C'est ce qui a été fait dans TensorFlow, par exemple, avec tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask , etc. Le résultat est un peu plus verbeux que surcharge [] , mais certainement plus transparent.

Une autre fonctionnalité qui peut aider sont les annotations de type, une fonctionnalité partiellement motivée par la difficulté de la transition Python 2 vers 3.

Je ne dis pas que ce serait facile. Dans mon esprit, les conséquences pour la communauté sont plus importantes. Cela prendrait en effet beaucoup d'énergie à mettre en œuvre puis à pousser en aval des projets comme SciPy.

@khinsen J'ai suivi la discussion toute la semaine et je pense que j'ai un problème de test pratique pour tester votre point de vue. Cela pourrait être un bon point pour voir comment votre point de vue gérerait de tels conflits au lieu de la discussion légèrement abstraite jusqu'à présent.

Actuellement, grâce au framework Apple Accelerate, la version minimale requise de LAPACK est 3.1.ish, qui date d'il y a plus de dix ans. Et actuellement LAPACK est à 3.8.0. Entre-temps, ils ont abandonné un certain nombre de routines (obsolètes et / ou supprimées) et corrigé de nombreux bugs et, surtout, introduit de nouvelles routines nécessaires pour combler le fossé entre les logiciels commerciaux et les logiciels scientifiques Python. Le résultat final est résumé ici . J'ai constamment ennuyé principalement

Il existe maintenant un besoin incontesté de versions plus récentes. Ce n'est pas la discussion et nous pouvons sauter cette partie en toute sécurité. Une partie importante des utilisateurs de NumPy et SciPy en bénéficieraient. Mais nous ne pouvons pas simplement l'abandonner à cause des arguments que vous avez déjà présentés. Comment résoudriez-vous cela?

Je ne demande pas cela de manière sournoise, mais comme tous les développeurs semblent se ressembler (et je dois dire que je suis d'accord avec eux), votre look peut peut-être donner une nouvelle idée. Devrions-nous garder Accelerate et créer un nouveau package NumPy / SciPy à chaque fois qu'une telle chose se produit? Si nous abandonnons le support pour innover, quelle est la meilleure façon de procéder selon vous?

Actuellement, grâce au framework Apple Accelerate, la version minimale requise de LAPACK est 3.1.ish

@mhvk , cela pourrait être un problème pour # 9976 dans 1,14, qui, je pense, nécessite 3.2.2 (modifier: déplaçons la discussion là-bas)

@xoviat : Ayons cette discussion sur cette question

@ilayn Merci d'avoir poussé cette discussion vers le concret et le constructif! Il y a en fait de nombreuses similitudes entre cette situation et celles qui m'ont motivé à démarrer ce fil.

Le principal point commun: il existe différents utilisateurs / communautés qui ont des besoins différents. Certains veulent Accelerate, d'autres veulent les nouvelles fonctionnalités de LAPACK. Les deux ont de bonnes raisons pour leurs priorités spécifiques. Il y a peut-être même des gens qui veulent à la fois Accelerate et les nouvelles fonctionnalités LAPACK, bien que ce ne soit pas clair pour moi.

Dans le monde Fortran / C, ce problème n'existe pas car les piles de logiciels sont moins profondes. Il y a Fortran, LAPACK et le code de l'application, sans intermédiaires supplémentaires. Ce qui se passe, c'est que chaque code d'application choisit une version particulière de LAPACK en fonction de ses priorités. Les centres de calcul conservent généralement plusieurs versions de LAPACK en parallèle, chacune dans son propre répertoire, le choix se faisant en modifiant le code d'application Makefile .

La leçon que nous pouvons et devrions retenir dans l'écosystème SciPy est que le choix des versions de logiciel n'est pas la tâche des développeurs de logiciels, mais des personnes qui assemblent des ensembles de logiciels spécifiques à une application. Dans notre monde, ce sont les personnes qui travaillent sur Anaconda, Debian et d'autres distributions de logiciels, mais aussi des gestionnaires de systèmes à différents niveaux et des utilisateurs finaux avec les bonnes compétences et la bonne motivation.

Donc, ma proposition pour le dilemme SciPy / LAPACK est de garder SciPy d'aujourd'hui en utilisant Accelerate, mais de le mettre en mode de maintenance minimale (éventuellement pris en charge par différentes personnes). Les gens qui veulent Accelerate peuvent alors choisir "SciPy 2017" et être heureux. Ils n'obtiendront pas les nouvelles fonctionnalités de LAPACK, mais probablement cela convient à la plupart d'entre eux. Le développement se poursuit dans un nouvel espace de noms ( scipy2 , scipy2018 ou autre), qui passe à LAPACK moderne. Si cela est techniquement possible, autorisez l'installation en parallèle de ces deux (et futures) variantes (ce qui, je pense, devrait être possible pour SciPy). Sinon, les personnes ayant besoin des deux devront utiliser plusieurs environnements (conda, venv ou environnements à l'échelle du système via Nix ou Guix). Notez que même dans ce deuxième scénario, je recommande fortement de changer l'espace de noms à chaque changement incompatible, pour m'assurer que les lecteurs de code Python à tous les niveaux comprennent pour quelle version de SciPy le code a été écrit.

L'idée générale est que les développeurs proposent de nouvelles choses (et se concentrent sur leur développement), mais ne les annoncent pas comme «meilleures» dans un sens général, ni comme un remplacement universel. Choisir la bonne combinaison de versions logicielles pour une tâche particulière n'est pas leur travail, c'est celui de quelqu'un d'autre.

L'idée générale selon laquelle le développement et l'assemblage sont effectués indépendamment et par des personnes différentes suggère également que les méga-packages actuels devraient être divisés en unités plus petites qui peuvent progresser à des rythmes différents. Il n'y a aucune raison aujourd'hui pour NumPy de contenir une petite interface LAPACK et des outils comme f2py . Pour SciPy, il peut être judicieux d'avoir un espace de noms commun indiquant la cohérence et une politique de développement commune, mais les sous-packages pourraient bien être distribués indépendamment. L'approche des méga-packages remonte à la devise de Python "batteries incluses", qui était géniale il y a 20 ans. La base d'utilisateurs actuelle est trop diversifiée pour cela, et le packaging de logiciels est généralement reconnu comme une activité distincte. L'inclusion des batteries devrait maintenant être le travail d'Anaconda.

Le principal obstacle à l'adoption d'une telle approche réside dans les distributions Linux traditionnelles telles que Debian ou Fedora avec leur approche «une installation Python par machine». Je pense qu'ils pourraient passer à plusieurs environnements virtuels à l'échelle du système avec un effort raisonnable, mais je n'y ai pas beaucoup réfléchi. Pour moi, l'avenir du packaging logiciel est constitué de systèmes basés sur l'environnement comme conda ou Guix.

Je ne vois pas comment toutes les prépositions que vous avez proposées jusqu'à présent sont compatibles avec l'une de ces étapes

• Vous venez de recréer la folie de l'image suivante
  
  Je viens de compter et j'en ai 27 exemplaires maintenant sur ma machine Windows. Multipliez maintenant cela par 10 depuis (les versions sont plus souvent ici) et par 2 (puisque les cycles de publication de NumPy et SciPy sont indépendants). En 2025, j'aurai facilement 15 copies de chaque bibliothèque et 10 LAPACK et 5 f2pys en tant que dépendances. Sans parler de la charge de maintenance pesant sur seulement une dizaine de personnes dans les deux packages, cela ne fonctionnera tout simplement pas. (C ++ n'est pas pertinent, insérez une bibliothèque standard de quoi que ce soit). Demandez Win à n'importe quel développeur de code commercial et dites-leur que c'est une si bonne idée. Je ne suis pas responsable de ce qui suit dans cet échange.
• Ensuite, vous avez augmenté la granularité des packages et vous faites maintenant tous les choses seuls avec différentes versions de packages; f2py a cassé quelque chose dans une version, donc SciPy arrête de construire dans la suivante mais dépend toujours de la version antérieure de NumPy. Une entité holistique devrait donc les rassembler gratuitement.
• Ensuite, vous avez également fait d'Anaconda (ou d'une autre entité) une entreprise d'une dépendance majeure, tout comme Accelerate l'était. Ou simplement, il y aura une abondance de «quelqu'un d'autre».
• Ensuite, vous avez mobilisé la plupart des utilisateurs dans un flux de travail qu'ils ne veulent vraiment pas (moi y compris) impliquant des environnements virtuels.
• Ensuite, vous avez même modifié les systèmes d'exploitation Linux au passage (ce qui est ... je veux dire, lisez simplement leurs listes de diffusion, c'est amusant).

Peut-être que vous vous êtes un peu écarté.

(Ceci est devenu une discussion libre pour tous, donc je vais aller de l'avant et intervenir).

Le problème avec le maintien de la prise en charge d'accélérer n'est pas qu'il manque les nouvelles API LAPACK. Si tel était le problème, nous pourrions expédier de nouvelles cales LAPACK et c'est terminé. Le problème est qu'il existe des fonctions de base qui renvoient des résultats incorrects dans certains scénarios. Il n'y a pas d'autre moyen de contourner cela que d'écrire nos propres fonctions BLAS. Et si nous faisons cela, nous pourrions tout aussi bien avoir besoin d'OpenBLAS ou de MKL.

@xoviat Tout cela a été discuté dans https://github.com/scipy/scipy/pull/6051. C'est comme d'habitude jamais aussi simple. Mais le but n'est pas de discuter de la suppression d'accélération, mais de l'utiliser comme cas d'utilisation pour le cycle de développement réel pour les nouvelles versions.

@ilayn Oui, je suis sûr que je connais déjà les points que je fais valoir. Mais le commentaire était pour @khinsen; Je pense qu'il a l'impression que nous pouvons réellement maintenir le support Accelerate.

On pourrait soutenir qu'une fonctionnalité (ou une limitation) de l'écosystème Python est que vous obtenez une version d'une bibliothèque sans l'horrible piratage de la transformation des noms. Cela se produit dans le noyau Python. C'est pourquoi il existe des bibliothèques nommées _lib_ et _lib_ 2 qui ont le même but mais des différences d'API. Même minerai Python fonctionne de cette façon. Il n'est pas possible de mélanger les bibliothèques standard entre les versions, même si les deux sont techniquement utilisables sur le Python moderne sans que quelqu'un ne les déchire et ne les place sur PyPi. Il y a beaucoup de questions StackOverflow à ce sujet, toutes avec la même conclusion.

@ilayn Si, pour une raison quelconque, vous voulez avoir toutes les combinaisons possibles de toutes les versions de tout sur votre machine, oui, c'est un gâchis. Mais pourquoi voudriez-vous cela? Si vous vous limitez aux combinaisons dont vous avez réellement besoin pour vos scénarios d'application, je parie que ce sera moins. A titre d'exemple, je garde exactement deux environnements Python sur ma machine: un avec Python 2 + NumPy 1.8.2 pour exécuter mon code vieux de 20 ans, et un représentant l'état de l'art d'il y a environ deux ans pour tout le reste ( il y a deux ans parce que je l'ai installé il y a deux ans et que je n'ai jamais vu de raison de le mettre à niveau après cela)

Quant à la granularité, je n’étais peut-être pas tout à fait clair dans ma proposition. Ce que je préconise, c'est plus de granularité dans l'emballage, pas dans le développement. Je m'attendrais à ce que le développement, par exemple, de f2py et de SciPy se poursuive en étroite coordination. f2py-2018 et SciPy-2018 devraient fonctionner ensemble. Cela ne veut pas dire qu'ils doivent être regroupés en une seule entité. L'objectif est de donner plus de liberté aux responsables de la distribution de logiciels pour faire leur travail.

Je ne veux certainement pas faire d'Anaconda ou de toute autre distribution une dépendance. Cela ressemble plus à «l'abondance de quelqu'un d'autre», même si je ne m'attends pas à ce que le nombre de distributions atteigne «l'abondance», étant donné que leur assemblage demande beaucoup de travail.

Je n'ai aucune idée de ce que veut le workflow "la base d'utilisateurs". Je vois beaucoup de bases d'utilisateurs différentes avec des exigences différentes. Personnellement, j'opterais pour plusieurs environnements, mais s'il y a une base d'utilisateurs importante qui souhaite un seul environnement par machine, une distribution s'en chargera. Mais les environnements virtuels ont été inventés pour une raison, ils résolvent un vrai problème. Les distributions au niveau du système comme Nix ou Guix les amènent à un autre niveau. Je ne m'attends pas à ce qu'ils disparaissent.

BTW, je suis en fait la liste de diffusion d'une distribution Linux (Guix). Pas très amusant, mais beaucoup de travail terre-à-terre. Je suis heureux qu'il y ait des gens qui font ça.

@xoviat Je n'ai pas suggéré de "conserver le support Accelerate". Je suggère simplement de conserver une variante de SciPy (à peu près la version actuelle) non pas comme une version obsolète pour le musée, mais comme une variante intéressante pour un groupe d'utilisateurs particulier: ceux pour qui utiliser Accelerate est plus important que de résoudre les problèmes qui Accélérer crée pour les autres. Les personnes «Accélérer d'abord» devront vivre avec les conséquences de leur choix. Certains problèmes ne seront jamais résolus pour eux. Cela leur convient probablement ("les bogues connus sont meilleurs que les bogues inconnus"), alors pourquoi les forcer à quelque chose de différent?

C'est vraiment une question d'étiquetage et de communication. Je veux m'éloigner de l'image idéalisée du logiciel en suivant un chemin linéaire de progrès, les versions plus récentes étant «meilleures» comme l'indiquent les numéros de version «plus élevés». Je souhaite remplacer cette image par une image que je considère plus réaliste: il n'y a pas de relation d'ordre évident entre les versions logicielles. Ceux produits par une communauté de développeurs cohérente de longue date ont un ordre temporel, mais cela n'implique rien sur la qualité ou l'adéquation pour une application donnée.

Si l'image idéalisée était juste, nous ne verrions pas de fourches et nous n'aurions pas d'environnements virtuels. Ni des projets tels que VersionClimber .

Ce que je propose, c'est que les développeurs de logiciels devraient embrasser cette réalité plutôt que de la nier. Ils devraient développer (et, surtout, emballer et étiqueter) leurs produits pour un monde de diversité.

@khinsen Si vous êtes d'accord avec les résultats incorrects des fonctions d'algèbre linéaire, alors nous pouvons continuer d'accélérer le support (note aux autres: je sais comment faire cela). Cependant, le principal problème est que vous pourriez être la seule personne à vouloir cela. Et même si vous ne l'êtes pas, que se passe-t-il lorsque quelqu'un sur la route blâme SciPy pour un problème d'accélération? Que se passe-t-il quand quelqu'un veut avoir son gâteau et le manger aussi? Je peux juste voir que cela se produit.

@xoviat Non, je ne suis pas d'accord avec les résultats incorrects des fonctions d'algèbre linéaire. Mais je suis sûr que de nombreux utilisateurs de SciPy n'ont pas du tout besoin des fonctions concernées. Dans le fil de discussion auquel vous avez fait référence, quelqu'un a suggéré de supprimer / désactiver les fonctions affectées lorsque Accelerate est détecté, ce qui, à mon avis, est une bonne solution (note: je ne peux pas juger de l'effort requis pour l'implémenter).

D'une certaine manière, cela fait partie du problème des méga-paquets. Avec une distribution plus granulaire, il serait plus facile de choisir ce qui fonctionne, à la fois au niveau du développement et de l'assemblage de distribution. On pourrait même imaginer un assembleur de distribution composant une distribution SciPy spécifique à un domaine et à une plate-forme dans laquelle différents sous-packages utilisent différentes versions de LAPACK, par exemple pour une utilisation dans des contextes HPC.

Mais je suis sûr que de nombreux utilisateurs de SciPy n'ont pas du tout besoin des fonctions concernées.

Il y a peu de preuves pour cette déclaration et je parierais en fait sur le contraire. Les fonctions sont largement utilisées mais échouent uniquement dans certains scénarios; en d'autres termes, vos résultats sont probablement corrects mais peuvent ne pas l'être. Oui, cela s'applique probablement au SciPy que vous avez actuellement installé si vous utilisez OSX. Oui, cela doit être corrigé.

En ce qui concerne le maintien d'une branche distincte, je ne pense pas que quiconque s'opposerait à vous donner un accès en écriture à une branche particulière pour que vous puissiez la maintenir. Mais ce sont des logiciels open source et les gens travaillent sur ce qu'ils veulent; Je suis sceptique que de nombreuses personnes seraient intéressées à maintenir cette succursale.

En fait, je pense que l'anaconda SciPy est compilé avec MKL, vous ne serez donc pas affecté dans ce cas. Mais alors pourquoi voudriez-vous accélérer le support?

@xoviat Il semble qu'il y ait un gros malentendu ici. Je n'ai aucun intérêt personnel du tout dans cette question spécifique. Je n'utilise aucune routine d'algèbre linéaire de SciPy.

Vous avez souligné un fil sur un problème SciPy et demandé comment je gérerais ce genre de situation. Le fil montre clairement une réticence à abandonner simplement le support Accelerate, dont j'ai déduit qu'il existe un groupe d'utilisateurs important qui serait affecté par un tel changement. Si ce groupe d'utilisateurs n'existe pas, où est le problème? Pourquoi SciPy n'a-t-il pas déjà abandonné le support Accelerate?

@xoviat Gérer une succursale distincte est facile pour tout le monde. Il n'est pas nécessaire qu'il soit hébergé dans le même référentiel GitHub. En d'autres termes, les succursales ne sont pas le problème. Le problème est l'espacement des noms, afin de rendre l'existence parallèle de versions séparées de SciPy transparente pour les utilisateurs (et les assembleurs de distribution).

Aujourd'hui, quand vous voyez du code disant "import scipy", vous n'avez aucune idée pour quelle gamme de versions de SciPy il est censé fonctionner (c'est-à-dire a été testé dans une certaine mesure). Dans le meilleur des cas, il y a un README disant "SciPy> = 0.8" ou quelque chose comme ça. Cette habitude est basée sur l'hypothèse que les versions "supérieures" sont toujours "meilleures" et ne dégradent jamais (casser, ralentir, ...) quoi que ce soit. Et cette hypothèse est tout simplement fausse.

Si, d'un autre côté, le code dit "import scipy2017 as scipy", alors il est clair pour chaque lecteur que son utilisation avec des versions antérieures ou ultérieures pourrait conduire à de mauvaises surprises. Et si les anciennes versions de SciPy disparaissent (effectivement, par manque de maintenance), un tel code échouera avec un message d'erreur, plutôt que de continuer à fonctionner de manière non fiable.

C'est le seul point que j'essaie de faire dans ce fil. La coexistence de différentes versions est une réalité. L'idée que plus c'est mieux est un rêve. Soyons réalistes et organisons-nous pour le monde réel, en reconnaissant un univers à versions multiples et en ajustant la communication de chacun pour éviter les malentendus.

Eh bien, je ne sais pas… à mon avis en ce qui concerne les avertissements, une importation de version spécifique n'est pas un avertissement, il est interdit d'utiliser une version différente, car les utilisateurs ayant des problèmes comme vous le décrivez n'oseront pas changer votre code. Un avertissement serait si vous imprimez un avertissement lors de l'installation / de l'exécution indiquant qu'il n'est pas testé pour toutes les versions numpy sauf spécifiques?

Je suppose que la création de ce type de packages supplémentaires est possible. Je m'attends aussi à ce que cela crée simplement un autre type d'enfer. Beaucoup de choses pourraient survivre, mais la vérification de type, par exemple, ne le sera pas et ne le pourra pas lorsque vous mélangez deux versions, donc fondamentalement, vous ne saurez pas si cela peut ou ne peut pas fonctionner jusqu'à ce que vous essayiez (et personne ne le testera!).
Et à moins que vous ne suggériez d'autoriser le mélange de deux versions, je pense que votre solution scipy2017 ne fera qu'empirer les choses. On dirait plus que nous aurions besoin de quelque chose comme le choix d'environnement virtuel dynamique / d'exécution (comme pin_import_version("1.6<numpy<1.10", level="raise") avant toute importation au niveau python).

L'importation spécifique a du sens si vous avez des changements prohibitifs majeurs (un peu comme py2 / py3), et nous avons déjà vu que nous avons des opinions différentes sur où et sur quelle échelle de temps cette ligne «majeure» semble se trouver.

La compatibilité descendante NEP # 11596 a été soumise, pouvons-nous fermer cela?

La compatibilité descendante NEP # 11596 a été soumise, pouvons-nous fermer cela?

Oui, nous pouvons fermer cela. Indépendamment de ce NEP (qui mentionne explicitement semver comme une alternative rejetée), le consensus des développeurs de base ici est que nous ne voulons pas changer en semver. D'où la fermeture comme wontfix.

Merci pour la discussion à tous.