Numpy: Anfrage: Verwenden Sie die semantische Versionierung

Könnte man davon ausgehen, dass numpy eine semantische Versionierung verwendet, jedoch mit einem führenden 1 ?

Beachten Sie, dass fast jedes wissenschaftliche Kernprojekt von Python das tut, was NumPy tut: Veralteten Code nach ein paar Veröffentlichungen entfernen, es sei denn, dies ist sehr störend, und nur die Hauptversionsnummer für wichtige Dinge erhöhen.

Sie sind sich nicht sicher, ob Sie eine Änderung der Verfallsrichtlinie vorschlagen oder ob Sie der Meinung sind, dass wir jetzt Version 14.0.0 anstelle von 1.14.09 verwenden sollten.

Letzteres: NumPy sollte jetzt ungefähr auf Version 14 sein. Ich schlage jedoch vor, diese Konvention nur für zukünftige Versionen zu übernehmen.

Übrigens: NumPys Vorgänger Numeric verwendete semantische Versionierung und erreichte über ein Jahrzehnt die Version 24. Ich weiß nicht, warum dies beim Übergang zu NumPy geändert wurde.

Mein Eindruck ist , dass die überwiegende Mehrheit der Python - Projekte nicht semantische Versionierung verwenden Sie. Beispielsweise verwendet Python selbst keine semantische Versionierung. (Mir sind auch keine gängigen Betriebssysteme oder Compiler bekannt, die Semver verwenden - haben Sie welche im Sinn?) Ich stimme zu, dass Semver-Befürworter eine großartige Arbeit bei der Vermarktung geleistet haben, was viele Entwickler zu dem Schluss gebracht hat, dass es gut ist Idee, aber AFAICT ist in der realen Welt für jedes Projekt, das größer als das linke Pad ist, im Wesentlichen nicht praktikabel, und ich bestreite nachdrücklich die Idee, dass die Semver-Leute jetzt das traditionelle MAJOR.MINOR.MICRO-Format "besitzen" und alle anderen zu etwas wechseln müssen sonst.

Können Sie ein Beispiel dafür geben, was Sie unter einem "Release-Labeling-Schema, das nicht mit semantischer Versionierung verwechselt werden kann" meinen? Verwenden Sie Namen anstelle von Zahlen? Sie zitieren eine datumsbasierte Versionierung, aber das häufigste Schema dafür, das ich gesehen habe, ist das von z. B. Twisted und PyOpenSSL, das derzeit bei 17.9.0 bzw. 17.5.0 liegt. Diese sehen für mich wie absolut plausible Semver-Versionen aus ...

Und können Sie erläutern, welchen Nutzen dies für die Benutzer haben würde? In dieser hypothetischen Zukunft würde jede Version einige wichtige Änderungen aufweisen, die für die Mehrheit der Benutzer wie jetzt irrelevant sind. Welche nützlichen Informationen würden wir vermitteln, wenn wir alle paar Monate die Hauptzahl erhöhen würden? "Das bricht wahrscheinlich jemanden, aber wahrscheinlich nicht dich"? Sollten wir auch die Hauptversion von Bugfix-Releases anstoßen, da es historisch unvermeidlich ist, dass ein großer Teil von ihnen den Code von mindestens einer Person beschädigt? Können Sie Beispiele für "Softwareentwickler, Softwarebenutzer und Manager von Softwareverteilungen" nennen, die tatsächlich verwirrt waren?

Beachten Sie, dass die Mailingliste ein geeigneterer Ort für diese Diskussion ist und wir wahrscheinlich eine Diskussion dort führen müssten, bevor wir tatsächlich Änderungen vornehmen. Die Kommentare hier sollten jedoch hilfreich sein, um ein Gefühl dafür zu bekommen, welche Art von Problemen Sie möchten in dieser Diskussion ansprechen.

@njsmith Es scheint, dass der einzige sachliche Punkt, über den wir uns nicht

Die informelle Untersuchung, die zu dem Schluss führte, dass die semantische Versionierung die Standardeinstellung ist, bestand darin, mit Administratoren wissenschaftlicher Computerinstallationen zu sprechen. Ich habe es mir auch vorgestellt
Ein empirischerer Ansatz (Auflistung der Pakete in einer aktuellen Debian-Installation und zufällige Auswahl einiger Pakete zur Untersuchung ihres Versionsansatzes) stellte sich jedoch als sehr schwierig heraus, da nur wenige Projekte eindeutig angeben, ob sie semantische Versionierung verwenden oder nicht.

Ein Kommentar eines Systemadministrators kam mir besonders relevant vor: Er sagte, dass für die Entscheidung, welche Version installiert werden soll, jede andere Konvention als die semantische Versionierung nutzlos ist. Systemadministratoren können weder jedes Paket im Detail untersuchen (ihnen fehlt die Zeit und die Kompetenz) noch alle Benutzer (zu viele von ihnen) konsultieren. Sie müssen eine einheitliche Richtlinie festlegen, die in der Regel auf der Annahme einer semantischen Versionierung basiert. Ein Administrator eines Computerclusters teilte mir beispielsweise mit, dass er sich mit einigen ihm bekannten "Hauptbenutzern" erkundigt, bevor er ein Update mit einer Änderung der Hauptversionsnummer anwendet.

Beispiele für Leute, die tatsächlich verwirrt waren, insbesondere in Bezug auf wissenschaftliche Python-Benutzer, ich habe viele von ihnen: Kollegen bei der Arbeit, Leute, die ich auf Konferenzen treffe, Leute, die per E-Mail um Rat fragen, Studenten in meinen Klassen. Dies beginnt normalerweise mit "Ich weiß, dass Sie ein Python-Experte sind. Können Sie mir bei einem Problem helfen?" Dieses Problem stellt sich als Skript heraus, das auf einem Computer funktioniert, auf einem anderen jedoch nicht. Die meisten dieser Leute berücksichtigen Abhängigkeitsprobleme überhaupt nicht, aber einige haben tatsächlich die Versionsnummern der beiden Installationen verglichen und nur "kleine Unterschiede" festgestellt.

Wie @ eric-wieser und @rgommers feststellten, ist meine Anfrage fast gleichbedeutend mit der Anfrage nach dem Anfangsbuchstaben "1". aus NumPy-Versionen entfernt werden. Mit anderen Worten, NumPy verwendet de facto bereits die semantische Versionierung, obwohl dies nicht das Ergebnis einer Richtlinienentscheidung ist und daher wahrscheinlich nicht rigoros erfolgt. Es wird jedoch darauf hingewiesen, dass NumPy die semantische Versionierung nahezu ohne Änderung des aktuellen Entwicklungsworkflows übernehmen könnte.

Ein Kommentar eines Systemadministrators kam mir besonders relevant vor: Er sagte, dass für die Entscheidung, welche Version installiert werden soll, jede andere Konvention als die semantische Versionierung nutzlos ist.

Leider ist die semantische Versionierung auch dafür nutzlos :-(. Ich will nicht Haare spalten oder übertreiben, ich verstehe total, dass es ein echtes Problem ist. Aber nur weil ein Problem real ist, heißt das nicht, dass es eine Lösung hat. Grundsätzlich können Sie die Frage "Soll ich diese Software aktualisieren?" Nicht auf eine einfache mechanische Überprüfung reduzieren. Es ist eine Fantasie. Projekte, die regelmäßig Semver verwenden, erstellen Hauptversionen, auf die alle Benutzer sofort aktualisieren sollten, und nehmen regelmäßig geringfügige Änderungen vor Veröffentlichungen.

Systemadministratoren können weder jedes Paket im Detail untersuchen (ihnen fehlt die Zeit und die Kompetenz) noch alle Benutzer (zu viele von ihnen) konsultieren. Sie müssen eine einheitliche Richtlinie festlegen, die in der Regel auf der Annahme einer semantischen Versionierung basiert. Ein Administrator eines Computerclusters teilte mir beispielsweise mit, dass er sich mit einigen ihm bekannten "Hauptbenutzern" erkundigt, bevor er ein Update mit einer Änderung der Hauptversionsnummer anwendet.

Ich mag diesen Teil aber :-). Ich bezweifle, dass wir uns über die Philosophie von Semver einig sind, aber es ist viel einfacher, über die konkreten Auswirkungen verschiedener Versionsschemata zu diskutieren und darüber, welches Ergebnis wir am wünschenswertesten finden.

Ich glaube nicht, dass das Konzept von Semver viel mit dieser Richtlinie zu tun hat. Überprüft der Systemadministrator, mit dem Sie gesprochen haben, tatsächlich jedes Projekt, um festzustellen, ob Semver verwendet wird? Wie Sie sagten, ist es bei den meisten Projekten nicht schwer zu sagen, welche dies tun. Und die Richtlinie ist dieselbe, die Sysadmins schon lange verwendet haben, bevor es überhaupt Semver gab. Ich denke, eine bessere Charakterisierung dieser Richtlinie wäre: "Befolgen Sie die Empfehlung des Projekts, wie vorsichtig ein Upgrade sein soll", zusammen mit der alten Tradition, dass Hauptversionen "groß" und Nebenversionen "klein" sind.

Die Empfehlung des NumPy-Projekts lautet, dass Systemadministratoren auf neue Feature-Releases aktualisieren sollten. Aus dieser Anekdote geht daher hervor, dass unser aktuelles Nummerierungsschema genau kommuniziert, was wir wollen, und dass ein Wechsel zu Semver nicht ...

@njsmith OK, wenden wir uns von der Philosophie ab und wenden uns den praktischen

Wieder scheint es, dass wir hier einen großen Meinungsunterschied haben. Für Sie sind es die Entwickler, die Systembetreuern und Benutzern Anweisungen geben und die Versionsnummern verwenden, um ihre Anweisungen zu übermitteln. Für mich sollte jeder Spieler nach seinen Kriterien entscheiden, und die Versionsnummer sollte auf gröbster Ebene als Mittel zur sachlichen Kommunikation dienen.

Da NumPy keine Auswirkungen auf die Sicherheit hat, verstehe ich nicht, wie und warum das NumPy-Projekt universelle Empfehlungen geben sollte. Menschen und Institutionen haben unterschiedliche Bedürfnisse. Aus diesem Grund haben wir sowohl ArchLinux als auch CentOS mit sehr unterschiedlichen Aktualisierungsrichtlinien.

@khinsen Das oldnumeric -Paket funktioniert immer noch einwandfrei und kann installiert werden mit:

pip install oldnumeric

Vielleicht könnte dies Ihr vorgeschlagener "stabiler Numpy" sein, bei dem die Schnittstelle zu Numpy auf Python / Cython beschränkt ist und nichts jemals geändert wird. Natürlich ist das Schreiben von Code mit Oldnumeric sehr geheimnisvoll, aber Sie können es nicht in beide Richtungen haben.

@ xoviat Stimmt, aber das ist ein anderes Problem. Mein Punkt hier ist nicht die Softwareerhaltung, sondern die Kommunikation zwischen den verschiedenen Akteuren im Software-Management.

Frage: Würden Sie als Systemadministrator (auch nur auf Ihrem PC) erwarten, dass ein Paket eine vollständige API-Schicht von Version 1.8 auf Version 1.9 löscht?

Für diejenigen, die mit "Ja" geantwortet haben, zweite Frage: Können Sie eine andere Software als numpy nennen, die dies jemals getan hat?

Übrigens kann ich Ihnen versichern, dass viele Menschen davon gebissen wurden, weil ich viele Mails erhielt, in denen ich gefragt wurde, warum MMTK von einem Tag auf den anderen nicht mehr funktioniert. Alle diese Personen hatten routinemäßige Aktualisierungen ihrer Softwareinstallationen durchgeführt, ohne ernsthafte Konsequenzen zu erwarten.

Das Fallenlassen von oldnumeric war jedoch nicht das schlimmste Ereignis in der jüngsten NumPy-Geschichte. Diese Ehre gilt der Änderung der Kopier- / Ansichtssemantik einiger Operationen wie diagonal . Code, der je nach NumPy-Version unterschiedliche Ergebnisse liefert (geringfügige Änderung der Versionsnummer!), Ist ein wahrer Albtraum.

Übrigens, da kaum jemand die Geschichte kennt: pip install oldnumeric funktioniert seit zwei Tagen, weil @xoviat dieses Add-On-Paket vorbereitet und auf PyPI gestellt hat. Vielen Dank!

Würden Sie erwarten, dass ein Paket eine vollständige API-Schicht von Version 1.8 auf Version 1.9 löscht?

Auf welche Ebene beziehen Sie sich?

Können Sie eine andere Software als numpy nennen, die dies jemals getan hat?

SciPy hat weave und maxentropy Pakete gelöscht, pandas bricht regelmäßig wichtige Funktionen. Ich bin sicher, es gibt noch viele weitere prominente Beispiele. BEARBEITEN: Python selbst finden Sie beispielsweise unter https://docs.python.org/3/whatsnew/3.6.html#removed

Übrigens kann ich Ihnen versichern, dass viele Menschen davon gebissen wurden, weil ich viele Mails erhielt, in denen ich gefragt wurde, warum MMTK von einem Tag auf den anderen nicht mehr funktioniert. Alle diese Personen hatten routinemäßige Aktualisierungen ihrer Softwareinstallationen durchgeführt, ohne ernsthafte Konsequenzen zu erwarten.

Diese Änderung dauerte ungefähr 10 Jahre, und es gibt keine Möglichkeit, dass ein anderes Versionsschema hier einen Unterschied gemacht hätte.

Das Löschen veralteter Funktionen ist ein Kompromiss zwischen dem Aufbrechen eines kleinen Teils des (älteren) Codes und der einfachen Pflege der Codebasis. Wenn wir uns irren, dann tun wir das wahrscheinlich eher konservativ. Als jemand, der sich auch mit vielen Jahre alten großen Unternehmenscodebasen befassen musste, die Numpy verwenden, spüre ich Ihren Schmerz, aber Sie plädieren für etwas, das absolut keine Lösung ist (und im Allgemeinen gibt es keine vollständige Lösung; Benutzer darüber aufzuklären Dinge wie das Anheften von Versionen und das Überprüfen auf Verfallswarnungen sind das Beste, was wir tun können.

Auf welche Ebene beziehen Sie sich?

Numerische / Numarray-Unterstützung nehme ich an

@rgommers Entschuldigung, ich hätte "ein weiteres Beispiel außerhalb des SciPy-Ökosystems" sagen sollen.

Außerdem beschwere ich mich nicht darüber, die Unterstützung für oldnumeric . Ich beschwere mich darüber, ohne die Hauptversionsnummer zu ändern.

Welchen Unterschied hätte das gemacht? Es hätte die Leute gezögert, ein Update durchzuführen, ohne die Versionshinweise zu lesen. Jeder, der Python-Code verwendet (aber nicht entwickelt), hätte dies als Zeichen genommen, um vorsichtig zu sein.

Vergessen Sie nicht, dass das SciPy-Ökosystem eine enorme Anzahl von unauffälligen Benutzern hat, die Entwicklungen nicht aktiv verfolgen. Python und NumPy sind Infrastrukturelemente der gleichen Art wie ls und gcc für sie. Und oft ist es weniger als das: Sie verwenden eine Software, die zufällig in Python geschrieben ist und zufällig von NumPy abhängt, und wenn sie kaputt geht, sind sie vollständig verloren.

@rgommers Entschuldigung, ich hätte "ein weiteres Beispiel außerhalb des SciPy-Ökosystems" sagen sollen.

Ich habe gerade meine Antwort mit einem Link zu den Python-Versionshinweisen bearbeitet, die sich außerhalb des SciPy-Ökosystems befinden.

Welchen Unterschied hätte das gemacht? Es hätte die Leute gezögert, ein Update durchzuführen, ohne die Versionshinweise zu lesen. Jeder, der Python-Code verwendet (aber nicht entwickelt), hätte dies als Zeichen genommen, um vorsichtig zu sein.

Dies wird einfach nicht der Fall sein. Wenn wir anstelle von 1.12, 1.13, 1.14 usw. 12.0, 13.0, 14.0 haben, gewöhnen sich die Benutzer daran und verwenden dieselbe Upgrade-Strategie wie zuvor. Die überwiegende Mehrheit wird nicht plötzlich viel konservativer werden.

Vergessen Sie nicht, dass das SciPy-Ökosystem eine enorme Anzahl von unauffälligen Benutzern hat, die Entwicklungen nicht aktiv verfolgen. Python und NumPy sind Infrastrukturelemente der gleichen Art wie ls und gcc für sie. Und oft ist es weniger als das: Sie verwenden eine Software, die zufällig in Python geschrieben ist und zufällig von NumPy abhängt, und wenn sie kaputt geht, sind sie vollständig verloren.

Alles wahr und alles nicht magisch durch eine Versionsnummer fixierbar. Wenn sie pip install --upgrade numpy , müssen sie wissen, was sie tun (und dies zeigt sowieso nicht einmal eine Versionsnummer an). Wenn es sich um ihr Verpackungssystem handelt, sehen sie das Problem, dass die Software nicht über eine anständige Testsuite verfügt (oder nicht ausgeführt wurde).

Weitere Nachteile der Änderung des Versionsschemas:

• Wir würden eine Änderung in der Versionierung vornehmen, ohne die Wartungsrichtlinien zu ändern. Dies wird eher verwirrend als hilfreich sein
• Wir folgen jetzt im Grunde Pythons Führung und tun dasselbe wie der Rest des gesamten Ökosystems. das ist eine gute Sache
• Vielleicht am wichtigsten: Wir würden die Fähigkeit verlieren, tatsächlich größere Veränderungen zu signalisieren. die Art, für die wir zu 2.x gehen würden, wie eine Veröffentlichung, die den ABI brechen würde.

Meine Basisreferenz ist nicht Python, sondern eine typische Softwareinstallation. Wie gesagt, für viele (vielleicht die meisten) Benutzer ist NumPy eine Infrastruktur wie gnu-coreutils oder gcc. Sie interpretieren Versionsnummern nicht speziell im Kontext des SciPy-Ökosystems.

Ich habe ein Debian 9-System mit ungefähr 300 installierten Paketen kurz überprüft. 85% von ihnen haben eine Versionsnummer, die mit einer Ganzzahl gefolgt von einem Punkt beginnt. Die häufigsten ganzzahligen Präfixe sind 1 (30%), 2 (26%), 0 (14%) und 3 (13%). Wenn NumPy ein Versionsnummerierungsschema einführen würde, das den allgemeinen Erwartungen entspricht (dh semantische Versionierung oder enge Annäherung), würde es definitiv auffallen und mit Vorsicht behandelt werden.

Beachten Sie auch, dass die einzigen Updates in der von Debian installierten Software, die mir jemals Probleme bereiteten, im SciPy-Ökosystem lagen, mit Ausnahme eines Emacs-Updates, das Änderungen im Organisationsmodus mit sich brachte, die eine selbst erstellte Erweiterung des Organisationsmodus beschädigten. Die insgesamt niedrigen Präfixe für die Versionsnummer scheinen daher darauf hinzudeuten, dass die am häufigsten verwendete Software viel stabiler ist als NumPy und Freunde.

Die Einheitlichkeit des SciPy-Ökosystems ist in der Tat wichtig, aber ich würde es vorziehen, wenn das gesamte Ökosystem ein Versionsschema einführt, das den Erwartungen der Außenwelt entspricht. Ich beginne nur mit NumPy, weil ich es als den grundlegendsten Teil betrachte. Es ist noch mehr Infrastruktur als alles andere.

Schließlich halte ich eine Änderung der Semantik einer Funktion für eine viel wichtigere Änderung als eine Änderung des ABI. Ersteres kann bei Hunderten von Benutzern zu Debugging-Albträumen führen und dazu führen, dass Programme jahrelang unentdeckte falsche Ergebnisse erzielen. Letzteres führt zu Fehlermeldungen, die deutlich auf die Notwendigkeit hinweisen, etwas zu beheben.

Nach diesen Standards folgt NumPy nicht einmal Pythons Vorbild, da die einzigen mir bekannten Änderungen in der Semantik in der Python-Sprache von 2 auf 3 erfolgten.

Schließlich halte ich eine Änderung der Semantik einer Funktion für eine viel wichtigere Änderung als eine Änderung des ABI. Ersteres kann bei Hunderten von Benutzern zu Debugging-Albträumen führen und dazu führen, dass Programme jahrelang unentdeckte falsche Ergebnisse erzielen. Letzteres führt zu Fehlermeldungen, die deutlich auf die Notwendigkeit hinweisen, etwas zu beheben.

Dies versuchen wir wirklich nicht zu tun. Ein deutlicher Bruch, wenn eine Funktion entfernt wird, kann auftreten, eine stille Änderung der numerischen Ergebnisse sollte dies nicht tun. Das ist eine Sache, die wir aus der Änderung der diagonalen Ansicht gelernt haben - das war im Nachhinein ein Fehler.

es würde definitiv auffallen und mit Vorsicht behandelt werden.

Ich bin immer noch anderer Meinung. Sogar unter Debian, was definitiv keine "typische Softwareinstallation" für unsere Benutzerbasis ist (das wäre so etwas wie Anaconda unter Windows). Sie scheinen auch mein Argument oben zu ignorieren, dass ein Benutzer normalerweise nicht einmal eine Versionsnummer sieht (weder mit pip install --upgrade noch mit einem Paketmanager).

Ihre Erfahrung, dass alles andere niemals kaputt geht, ist wahrscheinlich auch darauf zurückzuführen, dass Sie Dinge wie Betriebssystemdienstprogramme und GUI-Programme verwenden, nicht andere große Abhängigkeitsketten. Beispielsweise ist das gesamte JavaScript / NodeJS-Ökosystem wahrscheinlich anfälliger als das Python-Ökosystem.

Übrigens kann ich Ihnen versichern, dass viele Menschen davon gebissen wurden, weil ich viele Mails erhielt, in denen ich gefragt wurde, warum MMTK von einem Tag auf den anderen nicht mehr funktioniert

Dies ist ein gutes Beispiel für die Feinheiten hier. Soweit ich weiß, sind MMTK und Ihre anderen Projekte die einzigen noch vorhandenen, die von der Entfernung des Kompatibilitätscodes für numerische und numarray betroffen waren. Wie viele Benutzer würden Sie schätzen? 100? 1000? NumPy hat Millionen, also waren vielleicht 0,1% unserer Benutzer von dieser Entfernung betroffen? Dies ist definitiv nicht Null, und die Tatsache, dass es klein ist, bedeutet nicht, dass es keine Rolle spielt. Ich wünschte, wir könnten 100% der Benutzer für immer auf alle Arten unterstützen. Und ich verstehe, dass es für Sie besonders schmerzhaft ist, 100% der Beschwerden von Ihren Benutzern zu erhalten.

Aber wenn wir unsere Hauptversionsnummer dafür erhöhen, bedeutet dies für 99,9% unserer Benutzer, dass wir gerade Wolf geweint haben. Es ist falsch positiv. OTOH für diese 0,1% der Nutzer war es wirklich wichtig. Es ist jedoch nicht ungewöhnlich, dass wir trotz unserer Bemühungen mehr als 0,1% der Benutzer in Mikroversionen brechen. Also, was machen wir?

Es ist einfach nicht möglich, diese Nuancen über das stumpfe Instrument einer Versionsnummer zu kommunizieren. Jeder möchte aus guten Gründen schnell feststellen können, ob ein Upgrade seinen Code beschädigt. Semver ist beliebt, weil es das verspricht. Es ist aus dem gleichen Grund beliebt, aus dem man glaubt, dass Diäten Krebs heilen können. Ich wünschte, Semver würde auch seine Versprechen einhalten. Aber das ist nicht der Fall, und wenn wir gute Ingenieure sein wollen, müssen wir uns mit der Komplexität dieser Realität auseinandersetzen.

Ich verstehe nicht, wie und warum das NumPy-Projekt universelle Empfehlungen geben sollte. Menschen und Institutionen haben unterschiedliche Bedürfnisse.

Wir geben universelle Empfehlungen, da wir nur eine Versionsnummer haben. Per Definition ist alles, was wir damit machen, eine universelle Empfehlung. Darüber haben wir keine Kontrolle.

Diese Ehre gilt der Änderung der Kopier- / Ansichtssemantik einiger Operationen wie diagonal .

IIRC Wir haben buchstäblich keine einzige Beschwerde darüber von jemandem erhalten, der sagte, dass es seinen Code gebrochen hat. (Vielleicht eine Person?) Ich sage nicht, dass dies bedeutet, dass niemand betroffen war. Offensichtlich sind die Personen, die sich über eine Änderung beschweren, im Allgemeinen nur ein kleiner Teil der Betroffenen, aber wenn Sie Beschwerden als groben Stellvertreter für echte Probleme verwenden. Auswirkungen auf die Welt, dann denke ich nicht, dass dies die Top 50 macht.

Übrigens bin ich mir ziemlich sicher, dass Sie, wenn Sie die tiefe Geschichte durchsuchen, weitaus ungeheuerlichere Veränderungen finden können :-).

Beachten Sie auch, dass die einzigen Updates in der von Debian installierten Software, die mir jemals Probleme bereiteten, im SciPy-Ökosystem lagen, mit Ausnahme eines Emacs-Updates, das Änderungen im Organisationsmodus mit sich brachte, die eine selbst erstellte Erweiterung des Organisationsmodus beschädigten.

Ich denke, dies sagt mehr darüber aus, wie Sie NumPy gegen Debian verwenden, als über NumPy gegen Debian. Ich liebe Debian, ich benutze es seit fast 20 Jahren und ich kann nicht zählen, wie oft es kaputt ist. Erst in der letzten Woche hat ein bizarres Problem mit dem neuen Gnom meine Anmeldeskripte und ein anderes Upgrade meinen Trackpoint beschädigt . (Beide sind jetzt behoben, aber immer noch.) Ich werde auch bemerken, dass Debians Emacs so eingerichtet wurden, dass sie jahrelang Code über unverschlüsselte / unsichere Kanäle herunterladen und ausführen, da Bedenken hinsichtlich der Abwärtskompatibilität hinsichtlich der Aktivierung von Sicherheitsüberprüfungen bestehen. Ich glaube nicht, dass es so etwas wie eine gcc-Veröffentlichung gibt, die nicht ein paar Leute kaputt macht, schon allein, weil die Leute Dinge wie -Werror tun und dann geringfügige Änderungen im Warnverhalten (die sich auf subtile Faktoren stützen können) Interaktionen zwischen Optimierungsdurchläufen usw.) werden zu bahnbrechenden Änderungen.

Die insgesamt niedrigen Präfixe für die Versionsnummer scheinen daher darauf hinzudeuten, dass die am häufigsten verwendete Software viel stabiler ist als NumPy und Freunde.

Die insgesamt niedrigen Präfixe für die Versionsnummer sind darauf zurückzuführen, dass die am häufigsten verwendete Software kein Semver verwendet.

Schließlich halte ich eine Änderung der Semantik einer Funktion für eine viel wichtigere Änderung als eine Änderung des ABI. Ersteres kann bei Hunderten von Benutzern zu Debugging-Albträumen führen und dazu führen, dass Programme jahrelang unentdeckte falsche Ergebnisse erzielen. Letzteres führt zu Fehlermeldungen, die deutlich auf die Notwendigkeit hinweisen, etwas zu beheben.

Ja, deshalb sind wir bei solchen Änderungen äußerst vorsichtig.

Die Perspektiven sind hier etwas uneinheitlich: Sie scheinen zu glauben, dass wir die Dinge die ganze Zeit wohl oder übel ändern, uns nicht um die Abwärtskompatibilität kümmern usw. Ich kann das respektieren. Ich verstehe, dass es Ihre Erfahrung widerspiegelt. Wir haben jedoch die Erfahrung gemacht, dass wir bei solchen Änderungen äußerste Sorgfalt walten lassen, und ich würde sagen, wenn ich mit Benutzern spreche, sind es ~ 5%, die Ihre Perspektive haben, und ~ 95%, die der Meinung sind, dass Numpy entweder einen guten Job bei der Stabilität macht. oder dass es einen zu guten Job macht und eher bereit sein sollte, Dinge zu brechen. Vielleicht können Sie sich trösten, wenn Sie wissen, dass wir auch diese letzte Gruppe enttäuschen, wenn wir Sie enttäuschen :-).

mit der einzigen Ausnahme eines Emacs-Updates

Nun, um vom Thema abzukommen, das ist ein Beispiel für die andere Seite der Stabilität. Emacs war jahrelang statisch, da Stallman sich nicht ändern konnte, und das führte zur xEmacs-Gabel. Mein eigener Weg ging Emacs -> xEmacs, zum Teufel damit, -> Vim;) Vorzeitige Fossilisierung ist auch der Grund, warum ich früher aufgehört habe, Debian zu verwenden. Für einige Dinge ist eine Änderung einfach nicht erforderlich oder sogar erwünscht, und ich gehe davon aus, dass es Leute gibt, die alte Versionen von BSD auf alter Hardware ausführen, die in einem Schrank versteckt ist. Aber ich erwarte nicht, dass es viele solcher Orte gibt.

Angesichts des aktuellen Problems denke ich nicht, dass eine Änderung des Versionsschemas wirklich einen Unterschied machen würde. Ein produktiverer Weg könnte darin bestehen, das Modernisierungsproblem anzugehen. @khinsen Sehen Sie, wie Sie die Aktualisierung Ihrer Hauptprojekte akzeptieren können? Wenn ja, sollten wir nach Möglichkeiten suchen, wie wir Ihnen dabei helfen können.

Ich versuche die Projekte unter zu aktualisieren
https://github.com/ScientificPython. Dazu muss der Python-Code aktualisiert werden
benutzte die alte C-API (und ich meine alt; einige Funktionen wie Py_PROTO waren
ab 2000). PRs sind natürlich willkommen, aber ich bin mir nicht sicher, ob jemand
will ihre Zeit damit verbringen.

Das größere Problem, das er meiner Meinung nach angesprochen hat, ist, dass es "viele" gibt
Projekte "(Ich weiß nicht, wo genau sie sind, weil alle Projekte
dass ich gesehen habe, dass Python 3 unterstützt wird), das ebenfalls aktualisiert werden muss; Wie ist das
bestimmt, welchen Projekten NumPy-Entwicklerzeit zugewiesen wird? Und auch ich
Ich glaube nicht, dass seine zentrale Behauptung ungültig war: SciPy profitiert stark von der
Tatsache, dass es einfach alte fortran-Projekte kopieren und einfügen konnte (wie z
fftpack) mit wenig oder keiner Modifikation. Wenn diese geschrieben worden wären
"fortran 2" und neue Compiler haben dort nur "fortan 3" kompiliert
waren bedeutende Probleme.

Das heißt, diese Probleme sind nicht wirklich NumPys Schuld. Trotz allem, was er hat
sagte, mit NumPy 1.13 hat oldnumeric noch alle Tests bestanden,
Die Angabe des NumPy ist hier nicht der Schuldige. Da ist die oldnumerische API
buchstäblich über ein Jahrzehnt alt (vielleicht fast zwei Jahrzehnte!), und es immer noch
funktioniert auf dem neuesten NumPy, ich denke, dass die NumPy-API wahrscheinlich stabil ist
genug.

@charris Ich stimme Ihnen voll und ganz zu, dass "nie etwas ändern" keine produktive Einstellung im Computer ist.

Mein Punkt ist, dass das SciPy-Ökosystem so sehr populär geworden ist, dass kein einziger Ansatz zur Bewältigung von Veränderungen für jeden geeignet ist. Dies hängt davon ab, wie schnell sich Methoden und ihre Implementierungen in einem bestimmten Bereich entwickeln, von den technischen Kompetenzen der Praktiker, von anderer Software, von der sie abhängig sind, von den Ressourcen, die sie in Code investieren können usw.

Das derzeitige NumPy-Kernteam kümmert sich mehr um Fortschritte (in eine Richtung, die für einige Bereiche wichtig ist, für andere jedoch weitgehend irrelevant) als um Stabilität. Das ist in Ordnung - in der Open Source-Welt entscheiden die Leute, die die Arbeit machen, woran sie arbeiten wollen. Mein Eindruck ist jedoch, dass sie nicht erkennen, dass viele Menschen, deren Arbeit von NumPy abhängt, unterschiedliche Bedürfnisse haben, sich vom Entwicklungsteam verlassen fühlen und sich allmählich von SciPy zu traditionelleren und stabileren Technologien wie C und Fortran bewegen ( und in einem Fall weiß ich sogar Matlab).

Ich habe keine Ahnung, wie viel Prozent der NumPy-Benutzer mit dem aktuellen Stand der Dinge nicht zufrieden sind, und ich glaube, niemand anderes hat dies getan. Sobald ein Softwarepaket zur Infrastruktur wird, können Sie nicht leicht abschätzen, wer davon abhängt. Viele, die dies tun, sind sich dessen nicht einmal bewusst, und viel Code, der (direkt oder indirekt) von NumPy abhängt, ist nicht öffentlich und / oder nicht leicht zu entdecken.

Wenn wir alle in der SciPy-Community glücklich machen wollen, müssen wir einen Weg finden, um mit den unterschiedlichen Bedürfnissen umzugehen. Der allererste Schritt besteht meiner Meinung nach darin, die Kontrolle über die Änderungsrate in einer bestimmten Installation von den Entwicklern auf jemanden zu verlagern, der näher am Endbenutzer ist. Das können die Endbenutzer selbst oder Systemadministratoren oder Packager oder wer auch immer sein - auch hier glaube ich nicht, dass es eine universelle Antwort auf diese Frage gibt. Was dies von den Entwicklern verlangt, sind Informationen auf der richtigen Ebene, und deshalb habe ich diesen Thread gestartet. Natürlich können Versionsnummern die Welt nicht retten, aber ich sehe sie als ersten Schritt zum Aufbau einer verteilten Verantwortung für das Änderungsmanagement.

Schließlich scheinen einige von Ihnen zu glauben, dass ich einen persönlichen Kampf um meinen eigenen Code kämpfe. Es mag Sie überraschen, dass meine persönliche Einstellung nicht die ist, die ich hier verteidige. Mein eigener Sweetspot für die Änderungsrate liegt irgendwo zwischen dem, was in meinem Bereich üblich ist, und dem, was im NumPy-Team vorherrscht. Die meisten meiner heutigen Arbeiten verwenden Python 3 und NumPy> 1.10. MMTK ist 20 Jahre alt und ich mache heute viele Dinge anders. Sehr oft nehme ich Codeteile aus MMTK, die ich für ein bestimmtes Projekt benötige, und passe sie an "modernes SciPy" an, aber das kann ich nur mit Zuversicht tun, weil ich den Originalcode geschrieben habe.

Ich habe ein stabiles MMTK als Service für die Community gepflegt, nicht für meinen eigenen Gebrauch. Dies erklärt, warum ich die Wartung auf minimalistische Weise durchgeführt habe, um umfangreiche Änderungen in der Codebasis zu vermeiden. Sowohl die Finanzierung von Software- als auch von domänenkompetenten Entwicklern ist sehr schwer zu finden, daher ist MMTK immer ein Projekt geblieben, das nur einen Betreuer und gelegentliche Mitwirkende umfasst. Ich bin mir nicht einmal sicher, ob das Portieren von MMTK auf "modernes SciPy" irgendjemandem etwas nützen würde, da ein Großteil des Codes, der von MMTK abhängt, völlig unbeaufsichtigt ist. Aber das gilt für den größten Teil des Python-Codes, den ich um mich herum sehe, sogar für Code, der völlig unabhängig von MMTK ist. Es ist die Realität eines Forschungsbereichs, in dem Experimente anstelle von Berechnung und Codierung im Mittelpunkt der Aufmerksamkeit stehen.

@xoviat Die Anzahl der Tests in oldnumeric ist lächerlich gering. Ich würde nicht viel daraus schließen, dass sie mit NumPy 1.13 bestehen.

Die C-Erweiterungsmodule, die Sie sich angesehen haben, sind buchstäblich 20 Jahre alt und wurden für Python 1.4 geschrieben. Damals gehörte es zu den fortschrittlichsten Beispielen für Python-C-Combos und prägte tatsächlich die frühe Entwicklung von Numeric (Pre-NumPy) und sogar CPython selbst: CObjects (Pre-Capsules) wurden basierend auf den Anforderungen von ScientificPython und MMTK eingeführt .

Ich bin der erste, der sagt, dass die heutigen APIs und Support-Tools viel besser sind, und ich gehe davon aus, dass sie sich in Zukunft noch verbessern werden. Aber manche Leute wollen einfach zu bedienende Software für die Forschung zu tun, egal wie altmodisch es ist, und ich glaube , sie haben ein Recht , als auch zu existieren.

@rgommers Ich ignoriere Ihr Argument nicht, dass ein Benutzer nicht einmal eine Versionsnummer sehen kann. Es ist einfach nicht wahr für die Umgebungen, die Menschen um mich herum nutzen. Die Leute, die über Updates entscheiden (die nicht immer Endbenutzer sind), sehen es. Sie machen nicht nur einmal pro Woche "pip install --upgrade". Sie würden dies sogar als nachlässige Haltung betrachten.

Wenn Menschen in der Umgebung hauptsächlich Anaconda unter Windows verwenden, bestätigt dies nur, dass wir in sehr unterschiedlichen Umgebungen arbeiten. Ich hoffe, wir können uns im Zeitalter der Vielfalt darauf einigen, dass jede Gemeinschaft die Werkzeuge und Konventionen übernimmt, die für sie gut funktionieren.

Und ja, NodeJS ist schlimmer, da stimme ich zu. Zum Glück kann ich es leicht ignorieren.

Ich habe gerade eine E-Mail von einem Kollegen erhalten, der diesem Thread folgt, sich aber nicht traut, mitzumachen. Mit einer hervorragenden Analogie:

"Ich liebe es, wenn ich die Chance bekomme, ein neues Mikroskop zu kaufen und damit besser zu wissenschaftlich zu arbeiten. Aber ich würde es hassen, wenn jemand über Nacht mein Mikroskop austauschen würde, ohne mich zu konsultieren."

Es geht darum, die Kontrolle über die eigenen Werkzeuge zu haben.

Ich verspreche, ich werde niemals mitten in der Nacht in das Labor Ihres Kollegen einbrechen und dessen Anzahl verbessern. Ich besitze nicht einmal eine Sturmhaube .

Die Leute, die über Updates entscheiden (die nicht immer Endbenutzer sind), sehen es. Sie machen nicht nur einmal pro Woche "pip install --upgrade". Sie würden dies sogar als nachlässige Haltung betrachten.

Wenn sie Systemadministratoren sind und die Vor- und Nachteile verschiedener Installationsmethoden verstehen, sollten sie auch verstehen (oder lernen), wie die Versionierung in der Python-Welt (und vielen anderen Softwareprojekten, die ebenfalls keinen strengen Semver verwenden) funktioniert.

Das derzeitige NumPy-Kernteam kümmert sich mehr um Fortschritte (in eine Richtung, die für einige Bereiche wichtig ist, für andere jedoch weitgehend irrelevant) als um Stabilität.

Es tut mir leid, aber dies zeigt nur, dass Sie die NumPy-Entwicklung in den letzten Jahren überhaupt nicht verfolgt haben oder eine ganz bestimmte Brille haben. NumPy ist eigentlich ein sehr schwieriges Projekt, zu dem man beitragen kann, da die Abwärtskompatibilität sehr wichtig ist. Dies ist einer der Hauptgründe, warum es uns schwer fällt, neue Betreuer zu gewinnen.

und in einem Fall weiß ich sogar Matlab

Matlab war dafür berüchtigt, die Kompatibilität zu brechen. Das erste, was kooperative Projekte mit Matlab machten, war die Angabe der Version, die jeder verwenden musste, genau wie Microsoft Word, wenn es für die Dokumentation verwendet wurde. Ich kenne Leute, die genau wegen der verbesserten Kompatibilität zu NumPy gewechselt sind. Matlab hat seine Tugenden, aber Kompatibilität ist / war keine davon. Vielleicht haben sich die Dinge geändert?

Ich denke jedoch, dass wir in Zukunft einige Dinge tun können, die zur Kompatibilität beitragen könnten. Der erste knüpft an die aktuelle Diskussion der NEPs an. Jetzt, da NumPy ausgereifter ist, ist es möglicherweise eine gute Idee, NEPs stärker zu nutzen, wenn Änderungen vorgeschlagen werden, die sich auf die Kompatibilität auswirken, insbesondere wenn die NEPs öffentlicher und durchsuchbarer sind. Zweitens könnten wir versuchen, Räder für ältere NumPy-Versionen auf PyPI aufzustellen, wenn das nicht zu viel Arbeit ist. Die Verwendung virtueller Umgebungen scheint die derzeit beste Idee zu sein, um Reproduzierbarkeit zu erzielen, und eine größere Auswahl an Rädern zum Herunterladen könnte dabei helfen.

Zweitens könnten wir versuchen, Räder für ältere NumPy-Versionen auf PyPI aufzustellen, wenn das nicht zu viel Arbeit ist.

Dank der Bemühungen von @ matthew-brett sieht es so aus, als hätten wir derzeit Windows-Räder auf 1.10 , MacOS auf 1.5 (außer 1.7 fehlt ) und Linux auf 1.6 zurück .

Die MacOS / Linux-Situation scheint ziemlich vernünftig. Ich denke, wir könnten mehr Windows-Versionen nachfüllen? OTOH pip install unter Windows hat nie ohne heldenhafte Bemühungen funktioniert, daher bin ich mir nicht sicher, ob es dafür ein großes Publikum gibt. Wir haben bereits einen Wert von 2 Jahren und das wird mit der Zeit wachsen.

Als wir das letzte Mal alte Räder hochgeladen haben, wurde jemand wütend auf uns, weil sein Workflow davon ausging, dass es keine Räder gab und die Abwärtskompatibilität für sie unterbrochen wurde :-)

Würde gerne diese Geschichte hören.

Nicht, dass ich dieses Zeug wirklich gut kenne, aber ich denke, wir können versuchen, die Dinge zu verbessern (ich bin mir nicht ganz sicher, was das bedeutet!). Tatsache ist, wir müssen langsam vorankommen und bis auf möglicherweise einige Fehler waren alle Veröffentlichungen sollte nur sehr wenige Menschen Code brechen. Ich denke, unsere Nebenversion bedeutet "fast alle Leute sollten aktualisieren und aktualisieren können, ohne etwas zu bemerken", und ich glaube ehrlich, dass dies wahr ist. (Offensichtlich gibt es Dinge, die viele Menschen beeinflusst haben, wie z. B. ganzzahlige Abwertungen, aber sie führen nicht zu falschen Ergebnissen und waren lange in der Entwicklung)

Ich kann sehen, dass es einige Änderungen gegeben haben könnte, die groß genug sind, um die Hauptversion zu erhöhen, obwohl ich ehrlich gesagt nicht sicher bin, welche das sein würde. Und ja, vielleicht gibt es einen historischen Impulsverlust, wenn es um Hauptversionen geht.

Auf jeden Fall kann ich auch nicht sagen, dass ich ein Fan davon bin, (fast) jede Veröffentlichung ist eine Hauptveröffentlichung. Ich verstehe, dass wir vielleicht Leute mit einigen Änderungen verärgert haben, aber ich habe an einigen ziemlich umfangreichen Änderungen teilgenommen und jedes Mal, nachdem ich die Gründe erklärt habe, habe ich nur gehört, dass es das Richtige war, und wir haben auch darauf gewartet Jahre, bis diese Änderungen wirksam wurden.

Was gcc usw. betrifft. Zum Beispiel weiß ich nicht viel über das Kompilieren von / C ++. Ich habe mich über gcc 4.8 geärgert und mich gezwungen, herauszufinden, wie man Flags aufgrund einiger C ++ 11-Funktionen oder richtig ändert Es wird also erwartet, dass dies sehr ähnliche Reaktionen auf die E-Mails hervorruft, die Sie anscheinend über numpy bekommen, also bin ich mir nicht sicher, ob es viel anders ist :).

Wie auch immer, ich möchte hier nicht zu viel diskutieren, ich freue mich über das Feedback, ob wir zu schnell oder nicht vorsichtig genug sind, aber ich muss zugeben, dass ich auch nicht ganz sehe, dass das Ändern der Hauptversion viel helfen wird Das. Persönlich denke ich, dass 1.13 und 1.6 in gewissem Sinne mindestens eine Hauptversion voneinander entfernt sind, aber es gibt keine einzige Version dazwischen, auf die ich verweisen und sagen kann: Das war für viele Benutzer eine große Kompatibilitätspause.
Ich erinnere mich, dass ich Kommentare im Code gelesen habe: "Lass uns das vielleicht in Numpy 2 machen", genau aus Angst, überhaupt zu brechen. Bei diesem Ansatz befürchte ich, dass Numpy viel ins Stocken geraten wäre, und ehrlich gesagt bin ich ein bisschen stolz darauf, ein Teil davon zu sein von dem, was mir zumindest wieder als eine aktivere Phase erschien, die gebraucht wurde und die schwierig gewesen wäre, wenn wir noch konservativer gewesen wären. (Ich bin wahrscheinlich voreingenommen, da ich nicht viel Ahnung habe, was passiert ist, bevor ich gekommen bin :)).

Entschuldigung, vielleicht macht das keinen Sinn (wir hatten gerade eine Weihnachtsfeier). Der Semver-Vorschlag macht Sinn, aber ich muss zugeben, dass er sich nicht als echte Lösung anfühlt. Ich kann dem Versuch zustimmen, die Hauptversion aggressiver zu erhöhen, aber ich bin auch nicht damit einverstanden, grundsätzlich jede Version als Hauptversion zu bezeichnen. Ich kann auch dem Versuch zustimmen, in einigen Fällen konservativer zu sein, aber ich bin mir ehrlich gesagt nicht ganz sicher, was das ist (zähle einfach die Anzahl der hängenden PRs, weil niemand sicher ist, ob es irgendwo die Kompatibilität brechen könnte;), ich bin mir sicher ist eine gute Portion)?

Und selbst wenn ich Beschwerden gelesen habe, ist es nicht so, dass wir nicht jede Änderung rückgängig machen, wenn es vernünftigerweise möglich ist oder sie zumindest um ein Jahr oder länger verzögern, wenn Sie ein bisschen Abhören und Beharren mitbringen. Ich würde sagen, es ist ein Teil dessen, warum wir uns für ein konservatives Governance-Modell entschieden haben.

Also nach so langem Geschwätz:

• "Fast kein Code ist kaputt" scheint für eine Nebenversion vielleicht in Ordnung zu sein?
• Wir müssen langsam vorankommen?
• Die Dinge werden irgendwann kaputt gehen, und vielleicht könnten wir manchmal die Hauptversion erhöhen. Versuchen Sie möglicherweise sogar, einige FutureWarning-Typen in Hauptversionen stärker zu ändern. (Ich glaube ehrlich gesagt nicht, dass es helfen wird, aber ich bin bereit, es zu versuchen)

Am wichtigsten: Ich kenne die Frustration, aber gibt es eine echte Lösung für uns? Denken Sie, wenn wir die Hauptversion aggressiv erhöhen, erhalten Sie weniger E-Mails?

@xoviat fragst du nach der Geschichte über Beschwerden wegen des Hochladens von Rädern für alte Versionen? Das war # 7570.

Meine Lieblingsdefinition von semver (dass ich keinen Link mehr zum Originalbeitrag finde):

• major: Wir haben absichtlich den Benutzercode gebrochen
• Moll: Wir haben versehentlich den Benutzercode gebrochen
• Patch: Wir haben die Benutzerumgehungen für die Fehler der letzten kleineren Version unterbrochen

Das ist ein bisschen frech, aber ich denke, Treffer auf eine importierende Sache, _jede_ Verhaltensänderung wird irgendwo einen Benutzer kaputt machen. Dies gilt insbesondere für Projekte mit großen API-Oberflächen.

Der allererste Schritt besteht meiner Meinung nach darin, die Kontrolle über die Änderungsrate in einer bestimmten Installation von den Entwicklern auf jemanden zu verlagern, der näher am Endbenutzer ist.

Ich denke, etwas, das in dieser Konversation fehlt, ist, dass alte Versionen von Bibliotheken immer verfügbar sind (auf Pypi aus der Quelle). Wenn Sie also Code haben, der eine alte Version von Python / Numpy / Matplotlib erfordert, verwenden Sie die älteren Versionen. User-Space-Umgebungen machen dies nicht allzu schrecklich zu verwalten.

Wenn Sie neue Versionen der Bibliotheken verwenden möchten, müssen Sie die Kosten für die Aktualisierung der Änderungen bezahlen. Um die Mikroskop-Analogie voranzutreiben, müssen Sie Ihr Mikroskop routinemäßig warten, da es sich sonst mit der Zeit verschlechtert. Software ist nicht anders.

@njsmith Das ist ziemlich lustig. IMO # 7570 ist angesichts dessen kein gültiges Problem
NumPy entsprach der Manylinux-Radspezifikation. Im Allgemeinen Räder
sollte für ältere Versionen hochgeladen werden, vorausgesetzt, die Zeit ist frei. Gegeben
Diese Zeit ist nicht frei, wir könnten einfach feststellen, dass Menschen Räder bauen können
für eine bestimmte Version von NumPy, wenn sie diese wollen; Einreichung einer PR bei der
Numpy-Wheels-Repository. Oder nicht.

@ xoviat Ich meine, wenn ihr System kaputt ging, brach es; auf eine Spezifikation verweisen zu können, ändert daran nichts. Im Allgemeinen sollten wir uns in diesen Diskussionen mehr um die tatsächlichen Auswirkungen auf die Endnutzer als um die theoretische Reinheit kümmern. Aber OTOH in diesem Fall, denke ich, war es der richtige Anruf, die Räder hochzuhalten, da sie das Problem bereits umgangen hatten, die Räder bereits hochgeladen wurden und soweit wir das beurteilen können, gab es viel mehr Menschen, die davon profitierten als Probleme haben. Aber es ist eine interessante Erinnerung daran, wie subtil "Abwärtsinkompatibilität" sein kann und wie schwierig es ist, generische Regeln zu erstellen.

@njsmith Ihre Rolle in der Mikroskopanalogie ist die eines Mikroskopverkäufers, der sich mit einem Angebot an den Laborleiter meines Kollegen

@rgommers Ich verstehe, dass die Pflege von NumPy eine

Auf der anderen Seite gebe ich sicherlich zu, eine ganz bestimmte Brille zu haben, aber das gilt für alle anderen in dieser Diskussion. Meine Brille ist die des "traditionellen wissenschaftlichen Rechnens", das meine Arbeitsumgebung ist. Die Grundlinie (Standarderwartung) ist, dass Aktualisierungen niemals absichtlich etwas beschädigen. Das ist die Politik standardisierter Sprachen (C, Fortran), aber auch der Infrastrukturbibliotheken (BLAS, LAPACK, MPI, ...). Innovation findet trotzdem statt (zB ATLAS). Wenn Sie der Meinung sind, dass dies konservativ ist, lassen Sie mich beschreiben, was konservativ in meiner Welt bedeutet: Installieren Sie niemals eine Version von etwas, das nicht mindestens zwei Jahre alt ist, um sicherzustellen, dass die meisten Fehler bekannt sind. Dies ist eine gängige Richtlinie für Supercomputer, deren Zeit sehr teuer ist und deren Ergebnisse aus diesem Grund kaum überprüft werden können.

Beachten Sie, dass ich nicht sage, dass NumPy die Standarderwartungen meiner Welt übernehmen soll. Ich sage nur, es sollte klar signalisieren, dass es anders ist.

@seberg "Fast niemand Code ist kaputt" scheint theoretisch für eine Nebenversion in Ordnung zu sein. Sobald eine Software den Infrastrukturstatus erlangt hat (und meiner Meinung nach ist NumPy auf diesem Niveau), ist es unmöglich abzuschätzen, wie viele Entwickler und Benutzer betroffen sein könnten. Das Kriterium wird dann immer "fast niemand, an den ich denken kann, ist betroffen", und das ist kein gutes.

@tacaswell Ich denke, der Unterschied zwischen "absichtlich" und "zufällig" ist in der Praxis sehr wichtig. Es beeinflusst die Einstellung aller zu einer Veränderung. Schauen Sie sich nur andere Aspekte des Lebens an. Wenn die Unterscheidung keine Rolle spielt, könnten wir das Wort "vorsichtig" aus der englischen Sprache streichen.

Ehrlich gesagt denke ich, dass die Idee der "großen Sanierung" derzeit so gut wie aufgegeben wird, da sie entweder viel mehr Entwicklungskraft erfordert und dann möglicherweise auch eine ganz andere Art von Chaos verursacht (siehe py2 und py3 für die ersten Jahre).

Einverstanden, Numpy ist Infrastruktur, aber ich bin kein Fan davon, einfach so zu tun, als ob es in Ordnung wäre, den Code von mehr Leuten zu brechen / Absicht, größere Versionen schneller zu stoßen, ist eine Lösung. Es fühlt sich eher so an, als würde man die Aufgabe aufgeben, unser Bestes zu geben, um "fast niemand Code wird kaputt" -Versionen zu machen (möglicherweise mit der Ausnahme "es sei denn, Sie haben Warnungen für ein paar Veröffentlichungen nicht gesehen"), und dann tatsächlich bei der Entscheidung zu helfen der Aktualisierung.

Manchmal sollten wir wahrscheinlich anerkennen, dass dies möglicherweise nicht der Fall ist, aber ansonsten würde ich es vorziehen, Lösungen zu finden, um sicherzustellen, dass wir nicht mehr brechen. Natürlich haben Sie eine Lösung angeboten (sehr konservativ zu sein und Numpy 2 mit einer umfassenden Überarbeitung zu beginnen), aber was können wir noch tun, wenn wir zugeben, dass diese Lösung ohne größere Finanzierung oder so einfach nicht realisierbar ist?

Oder lassen Sie mich klar sein: Wenn Sie jemanden kennen, der in der Lage ist, numpy dev zu folgen, und der darauf achten kann, dass er bei Bedarf konservativer ist, wissen Sie, dass ich es zumindest schätze. Aber ich persönlich schätze es nicht, unseren Fortschritt aufzugeben, zumindest einige der dunkleren Ecken langsam loszuwerden, um eine zukünftige Entwicklung zu ermöglichen. Im besten Fall würden wir in ein paar Jahren einen toten NumPy und einen Ersatz bekommen, im schlimmsten Fall werden wir nur überholt und stromabwärts frustriert sein, weil wir nicht in der Lage sind, vorwärts zu kommen, und vielleicht "Ersatz" entstehen, der von Natur aus sprießt Wenn Sie nicht annähernd so reif sind, machen Sie es nur noch schlimmer.

Ich muss @seberg bei der Erstellung eines anderen Namespace zustimmen. Das
Die gesamte Annahme hinter dieser Idee ist, dass das NumPy-Projekt unbegrenzt ist
Talent und Ressourcen, um eine Bibliothek zu unterhalten, die für alle funktioniert.
Dies ist jedoch nicht der Fall. Entwickler sind nicht perfekt, also normalerweise
Verstehe es beim ersten Mal falsch. Die Leute, die den ursprünglichen numerischen Code schreiben
konnte nicht alle Szenarien vorhersagen, in denen es verwendet werden würde, und sie
konnte den Aufstieg alternativer Implementierungen wie PyPy nicht vorhersagen.

Ich denke, dass API-Stabilität sehr wichtig ist. Ich denke auch, dass NumPy hat
im Allgemeinen richtig gemacht. Tatsache ist, dass NumPy bereits vorhanden ist
schwer zu überlegen (und es sollte sein, angesichts der Tatsache, dass jede letzte Unze von
Leistung ist wichtig), aber das Erstellen eines anderen Namespace würde es schaffen
Es ist äußerst schwierig, alle Auswirkungen einer Codeänderung beizubehalten
dein Kopf. Ich denke, es ist sehr wahrscheinlich, dass NumPy dies tun würde
deutlich mehr Fehler sein, weil Entwickler das nicht verstehen
Auswirkungen der Änderung des Codes in einer Schnittstelle auf der anderen.

Zusammenfassend verstehe ich die Frustrationen der Menschen vollkommen. Aber als @njsmith
sagte, es gibt keine Lösungen für das Problem, die jeden Benutzer zufriedenstellen.
Es gibt nur Lösungen, die die meisten Benutzer die meiste Zeit zufrieden stellen. Und
Die Realität ist, dass wenn NumPy sich an die Minderheit der Benutzer wendet (nicht gemeint)
in abfälliger Weise), die API-Stabilität über alles andere forderte, die
Die NUMFOCUS-Finanzierung könnte versiegen, weil nicht klar wäre, was das Geld ist
wurde verwendet, und wo würden wir dann sein? Wahrscheinlich in einer Situation, in der
MMTK kann sich nicht mehr auf NumPy verlassen, genau wie die Situation, in der dies möglich ist
hängen nicht mehr von Numeric ab.

Ich würde den aktuellen Code in den Minimalwartungsmodus versetzen und mit einer umfassenden Neugestaltung in einem anderen Namespace beginnen, sodass Alt und Neu unbegrenzt mit Interoperabilität über die Pufferschnittstelle koexistieren können. Und ja, ich weiß, dass dies aus vielen Gründen kein triviales Unterfangen ist, aber ich denke, es ist der einzige Weg, aus dem Haufen akkumulierter technischer Schulden herauszukommen. Das Hauptziel der Neugestaltung wäre die Wartbarkeit.

Ich stimme Ihnen tatsächlich zu, aber ich sehe nicht, wie es ohne eine größere Menge an Finanzmitteln / Visionen machbar ist. NumPy ist ein riesiges Werk. Vielleicht schaffen es @teoliphant und @skrah mit Plures , aber es wird ein harter Kampf.

Angesichts der NumPy, die wir heute haben, denke ich, dass wir so gut abschneiden, wie wir es vernünftigerweise tun können.

Für diejenigen, die mit "Ja" geantwortet haben, zweite Frage: Können Sie eine andere Software als numpy nennen, die dies jemals getan hat?

django ist eine weitere bemerkenswerte Software, die keine semantische Versionierung verwendet. Sie verwenden wichtige Änderungen, um auf wesentliche Unterbrechungen hinzuweisen, verwerfen jedoch Änderungen an .x-Änderungen nach einer langen Zeit der Warnungen. Mehr oder weniger wie NumPy.

Ich stimme dir tatsächlich zu,

@ Shoyer aus Interesse, warum? Wie würde das nicht irgendwann zu einem sehr schmerzhaften py3k-ähnlichen Übergang zur neuen Codebasis werden?

Das ist die Politik standardisierter Sprachen (C, Fortran), aber auch der Infrastrukturbibliotheken (BLAS, LAPACK, MPI, ...). Innovation findet trotzdem statt (zB ATLAS).

Innovation im Tempo von LAPACK / ATLAS / OpenBLAS ist ein Rezept dafür, dass NumPy viel schneller irrelevant wird, als es sonst der Fall wäre.

Schauen Sie, es muss Ihnen aus allen Antworten klar sein, dass diese Versionsänderung nicht stattfinden wird, und das ist der Konsens zwischen den ~ 7 aktiven Kernentwicklern und einigen Entwicklern großer nachgelagerter Projekte. Wenn Sie absolute Stabilität benötigen, ist es wahrscheinlich am besten, wenn Sie einige Jahre lang nur eine feste Version auf Ihren Systemen anheften und Ihre Systemadministratoren darüber informieren.

Wie würde das nicht irgendwann zu einem sehr schmerzhaften py3k-ähnlichen Übergang zur neuen Codebasis werden?

Der große Unterschied besteht darin, dass Python 3 zwar ein Alles / Nichts-Schalter ist (für Python-Programme), es jedoch einfach oder zumindest machbar ist, verschiedene ndarray-Bibliotheken zu mischen / abzugleichen. Über die Pufferschnittstelle können Sie Daten ohne Kopien hin und her übertragen. Wenn Sie Eingaben in Ihre Funktionen mit np.asarray() erzwingen, bemerken Sie möglicherweise nicht einmal, ob eine Bibliothek, mit der Sie arbeiten, Schalter verwendet, um Arrays eines anderen Typs zurückzugeben.

Dies klingt wie das Wiederholen von Teilen des numerischen / numarray / numpy
Erfahrung, die auch nicht sehr angenehm war (die Pufferschnittstelle wird
Hilfe, aber ich denke, ein solcher Übergang wird immer noch manuellen Code beinhalten
Änderungen, von denen nicht alle trivial sind). Es wird auch nicht möglich sein
für Bibliotheken wie Scipy "Upgrade" auf das "neue Array" ohne
Die Abwärtskompatibilität wird unterbrochen, sodass das Problem nur noch zunimmt
das Ökosystem und zwingt andere Bibliotheken, eine ähnliche Entscheidung zu treffen
alte Namespaces aufgeben.

Wenn jeder seine Eingaben mit np.asarray erzwingen würde, wäre np.matrix kein Problem :-).

Wenn sich verschiedene Array-Bibliotheken auf Ententypen einigen können und wir uns auf d-Typen beschränken, die durch das Pufferprotokoll dargestellt werden können, kann dies funktionieren. Aber wenn der Sinn eines Umschreibens darin besteht, inkompatible Schnittstellenänderungen an den Array-Objekten vorzunehmen und neue dtypes zu implementieren, ... sehe ich wirklich nicht, wie es funktioniert. Konkretes Beispiel: Eine naheliegende Sache, die bei dieser Art des Umschreibens behoben werden muss, ist das Verhalten von ndarray.dot bei hochdimensionalen Eingaben. Wenn es jedoch eine Bibliothek gibt, die def f(a, b): a.dot(b) ausführt, wird sie durch das Erstellen einer solchen Bibliothek möglicherweise beschädigt. Es spielt keine Rolle, ob diese Bibliothek numpy heißt oder nicht.

Und das, bevor wir überhaupt in die allgemeine Unmöglichkeit geraten, alles in einem einzigen Knall neu zu schreiben, die Aufmerksamkeit der Entwickler aufrechtzuerhalten, während wir das tun, und es nicht nur richtig zu machen, sondern so viel besser zu machen, dass es die Leute davon überzeugen kann, zu migrieren - alles ohne inkrementelles Feedback von Benutzern. Ich denke, Dynd ist hier ein lehrreiches Beispiel.

@rgommers Bitte lesen Sie noch einmal, was ich geschrieben habe: Ich wiederhole nicht , dass NumPy das Tempo von LAPACK übernehmen soll. Ich schlage vor, dass es Menschen, die eine solche Erwartung haben (dh 80% der Menschen in meiner Umgebung), klar signalisiert, dass dies nicht der Fall ist.

@njsmith Ein Hauptaspekt eines Redesigns, wie ich es sehe, wäre, OO aufzugeben. Es ist kein guter Ansatz, um Code für eine einzelne Datenstruktur mit Tonnen von Funktionen zu strukturieren, die daran arbeiten. Schreiben Sie np.dot(a, b) und das von Ihnen beschriebene Problem verschwindet sofort. Sie können beliebig viele Implementierungen von namespace.dot . Jede Bibliothek kann diejenige verwenden, die sie mag, und sie können weiterhin zusammenarbeiten. Es ist OO, das einen einzelnen Namespace für Methoden erstellt, und das ist ein Problem.

Ja, das ist ein großer Bruch mit den Python-Gewohnheiten. Und ja, es wird schwierig sein, darüber hinaus Operatoren zu implementieren. Aber ich denke, es kann getan werden, und ich denke, es ist die Mühe wert.

Nur um zu zeigen, dass ich dafür sein kann, Dinge zu brechen ;-)

@rgommers Bitte lesen Sie noch einmal, was ich geschrieben habe: Ich wiederhole nicht, dass NumPy das Tempo von LAPACK übernehmen soll.

Ich verstehe das. Die beiden Absätze meiner Antwort standen nicht in direktem Zusammenhang, sorry, wenn das verwirrend war.

Ich schlage vor, dass es Menschen, die eine solche Erwartung haben (dh 80% der Menschen in meiner Umgebung), klar signalisiert, dass dies nicht der Fall ist.

Das habe ich gesagt, Konsens scheint zu sein, dass Ihr Vorschlag abgelehnt wird. Sie müssen einfach eine angeheftete Version für diese 80% anfordern und erklären, warum Sie das wollen.

@khinsen OK, dann tun Sie stattdessen so, als wäre mein Beispiel die inkompatiblen Änderungen in der Indizierung, die wir sicherlich vornehmen würden, wenn es möglich wäre. (Fancy Indexing hat einige außerordentlich verwirrende Eckfälle.)

@njsmith In gewisser Weise das gleiche Problem. Die Indizierung ist ein Methodenaufruf in Python, also wieder OO.

Nebenbemerkung: Ausgefallene Indizierung ist meiner Meinung nach der größte Designfehler bei NumPy, da es nicht einmal eine eindeutige Spezifikation hat (und nie hatte). Es macht np.take für ganzzahlige Argumente und np.repeat für boolesche Argumente. Da Boolesche Werte in Python ein Subtyp von Ganzzahlen sind, entsteht eine Mehrdeutigkeit für Argumente, die nur Nullen und Einsen enthalten.

Es gibt tatsächlich eine Beziehung zum Thema dieses Threads, da dies genau die Art von Designfehler ist, die auftritt, wenn die Entwicklung zu schnell voranschreitet.

Ich diskutiere in meinen SciPy-Kursen ausschließlich über ausgefallene Indizierung, um den Leuten zu sagen, dass sie sie nicht verwenden sollen. Es gibt np.take und np.repeat die perfekt funktionieren und keine Probleme verursachen. Und wenn Sie sie eher als Funktionen als als Methoden verwenden, gibt es auch kein OO-Problem. Für diejenigen, die np.repeat nicht mögen, weil der Name nicht die Absicht nahe legt, wenn er mit Booleschen Werten verwendet wird, führen Sie einfach einen Alias ​​ein: select = np.repeat . Wieder etwas, das OO unnötig erschwert hat.

Beachten Sie auch, dass die einfache Indizierung keinem solchen Problem unterliegt. Es macht das, was so ziemlich jeder von ihm unter allen möglichen Umständen erwarten würde, so dass es in einer Methode implementiert werden kann.

Das heikle Thema ist aus meiner Sicht die Arithmetik. Sie möchten zwar a+b für das Hinzufügen von Arrays schreiben, anstatt np.add(a, b) , aber es gibt keine allgemeine Vereinbarung darüber, was genau a+b tun soll, insbesondere in Bezug auf den Ergebnistyp . Dies war eines der Kernthemen des Numeric / Numarray-Split, das zur Einführung neuer Skalartypen in NumPy führte, und diese verursachen auch einen angemessenen Anteil an unangenehmen Überraschungen. Ich glaube, dieses Problem kann gelöst werden, aber nicht in Nebenbemerkungen zu einer Diskussion über GitHub-Probleme.

@rgommers Wenn es möglich gewesen wäre, "eine

Dies ist der Punkt, den ich versuche, indem ich darauf bestehe, dass NumPy Infrastruktursoftware ist. Für viele Menschen ist es nur einer von Hunderten von Legosteinen, aus denen sich ihre Softwareinstallation zusammensetzt. Sie kümmern sich nicht speziell darum, es muss nur da sein und "arbeiten".

Ich möchte dies nicht zu sehr entgleisen, aber ich habe keine Ahnung, worauf Sie sich mit np.repeat- und bool-Arrays beziehen

@ eric-wieser 0 mal wiederholen und du entfernst es 1 mal aus dem Array und es bleibt. Ich bin nicht damit einverstanden, dies zu lehren, anstatt es zu indizieren, aber was auch immer (die schlimmste Seltsamkeit ist heutzutage verschwunden, also ist ein Bool in den meisten Fällen kein Int Listen, wenn Sie es so sehen möchten, aber ...).

Ein Nebenpunkt, da das sowieso nirgendwo mehr hingeht :). Ich hoffe tatsächlich etwas, dass das langsame Reparieren von Sachen in Numpy es irgendwann einfacher macht, Numpy in Zukunft austauschbarer zu machen.

Ihr Vorschlag ist ein bisschen wie "Windows-Benutzer auffordern, zu Linux zu wechseln" (oder umgekehrt).

Hmm, technisch kompetente Leute (ich hoffe ...) zu fragen, wie Versionsnummern in der realen Welt tatsächlich funktionieren, ist eigentlich nichts anderes als ein Wechsel von Windows zu Linux.

Dies ist der Punkt, den ich versuche, indem ich darauf bestehe, dass NumPy Infrastruktursoftware ist.

Und wenn wir diesen Wechsel vornehmen würden, würden Sie vermutlich zu SciPy wechseln, weil es das nächste Stück Infrastruktur ist? Wann hört es auf, Infrastruktur zu sein? Und warum sollten NumPy und die anderen Teile der Infrastruktur ein völlig anderes Versionsschema haben als Python selbst und der Rest des gesamten wissenschaftlichen Python-Ökosystems?

Diese 80% "sind keine organisierte Community, mit der Sie sprechen können.

Die Administratoren für die Supercomputer, die Sie verwenden, sollten wirklich miteinander sprechen, oder? Es kann nicht viele Leute geben, die auf diesen beiden Systemen um die gesamte Aktualisierungssoftware herumlaufen und nie reden. Ich wollte nicht, dass Sie 80% aller Sysadmins weltweit unterrichten, nur die, die Sie brauchen.

@seberg Die Erklärung, dass Listen und Arrays unterschiedliche Datentypen sind, die nur die Indizierung als gemeinsame Eigenschaft verwenden, ist eine gültige Sichtweise. Dies würde auch die Erklärung bestimmter NumPy-Skalare erleichtern. Aber ich habe keine Präsentation von NumPy gesehen, die diesen Standpunkt vertritt.

@rgommers

Die Administratoren für die Supercomputer, die Sie verwenden, sollten wirklich miteinander sprechen, oder?

Nein, sie wissen nicht einmal über die Existenz der anderen Bescheid. Sie arbeiten für verschiedene Organisationen an verschiedenen Orten, deren einzige Gemeinsamkeit darin besteht, einige Benutzer gemeinsam zu haben.

Ich wollte nicht, dass Sie 80% aller Sysadmins weltweit unterrichten, nur die, die Sie brauchen.

Hier geht es nicht um mich - ich habe eine Lösung, die für mich perfekt funktioniert: Ich installiere Python plus alle Bibliotheken aus dem Quellcode immer in meinem Home-Verzeichnis.

Hier geht es um Menschen, mit denen ich zusammenarbeite, und um Menschen, die mich um Hilfe bitten (z. B. weil sie in der Vergangenheit an einem meiner Python-Kurse teilgenommen haben). Sie verfügen nicht über die technische Kompetenz, um ihre eigene Python-Installation zu verwalten und sich an eine andere Person (Administrator oder erfahrener Kollege) zu wenden.

um zu erfahren, wie Versionsnummern in der realen Welt tatsächlich funktionieren

In der gemeinsamen Hintergrundkultur der Menschen, an die ich denke, funktioniert die reale Welt tatsächlich wie eine semantische Versionierung oder eine enge Annäherung.

In der gemeinsamen Hintergrundkultur der Menschen, an die ich denke, funktioniert die reale Welt tatsächlich wie eine semantische Versionierung oder eine enge Annäherung.

Das liegt daran, dass sie eine begrenzte Anzahl von Bibliotheken verwenden, die sich meist langsam bewegen wie LAPACK & Co. Wie @njsmith hervorhob , hat die Mehrheit der Software niedrige Versionsnummern, da sie keine semantische Versionierung verwenden.

@rgommers Sie verwenden meistens langsame Bibliotheken, obwohl ich nicht "eine kleine Zahl" sagen würde.

Wie @njsmith hervorhob , hat die Mehrheit der Software niedrige Versionsnummern, da sie keine semantische Versionierung verwenden.

Nach meiner Erfahrung nicht. Aber dann bedeutet "Mehrheit" wahrscheinlich "die meisten von denen, die ich kenne", sowohl für Sie als auch für mich, und es gibt wahrscheinlich kaum Überschneidungen zwischen den von Ihnen verwendeten und den von mir verwendeten Paketen außerhalb des SciPy-Ökosystems.

Und wenn wir diesen Wechsel vornehmen würden, würden Sie vermutlich zu SciPy wechseln, weil es das nächste Stück Infrastruktur ist? Wann hört es auf, Infrastruktur zu sein?

Ich würde es in der Tat vorziehen, dass SciPy und alle anderen Grundlagen des SciPy-Ökosystems dieselben Prinzipien anwenden, aber ich persönlich werde keine Anstrengungen unternehmen, um irgendwo anders als für NumPy zu argumentieren, das weitaus häufiger verwendet wird als jedes andere die anderen Bibliotheken und auch weitaus grundlegender. NumPy-Arrays sind die zentrale Datenstruktur für viele wissenschaftliche Software, während SciPy nur eine riesige Sammlung von Funktionen ist, aus denen eine bestimmte Anwendung eine kleine Teilmenge verwendet.

Beachten Sie auch, dass SciPy de facto eine semantische Versionierung verwendet, wenn auch wahrscheinlich nicht absichtlich, da es gerade erst 1.0 erreicht hat.

Und warum sollten NumPy und die anderen Teile der Infrastruktur ein völlig anderes Versionsschema haben als Python selbst und der Rest des gesamten wissenschaftlichen Python-Ökosystems?

Das gesamte SciPy-Ökosystem sollte in der Tat denselben Ansatz verwenden, der (wie ich es sehe) der dominierende im wissenschaftlichen Rechnen ist. Dies gilt nicht für Python- und Python-Bibliotheken anderer Domänen, die andere Gewohnheiten haben. Beispielsweise ist die Webentwicklung viel weniger konservativ als das wissenschaftliche Rechnen. Es wird auch meistens von verschiedenen Leuten gemacht, die sich um verschiedene Benutzer kümmern. Die Python-Sprache wäre der einzige Ansprechpartner.

NumPy-Arrays sind die zentrale Datenstruktur für viele wissenschaftliche Software, während SciPy nur eine riesige Sammlung von Funktionen ist, aus denen eine bestimmte Anwendung eine kleine Teilmenge verwendet.

Und die zentrale Datenstruktur ist stabil. Die große Mehrheit der inkompatiblen Änderungen in einer bestimmten Version sind Eckfälle und meistens nicht im ndarray-Verhalten. Siehe beispielsweise https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes. Beachten Sie auch, dass keine dieser Änderungen für einen Systemadministrator eine Bedeutung haben würde. Selbst wenn sie diese Notizen lange anstarrten (wenn dies 2.0.0 gewesen wäre), könnten sie nicht entscheiden, ob ein Upgrade in Ordnung war oder nicht nicht.

Beachten Sie auch, dass SciPy de facto eine semantische Versionierung verwendet, wenn auch wahrscheinlich nicht absichtlich, da es gerade erst 1.0 erreicht hat.

SciPy verwendet genau das gleiche Versionsschema und die gleiche Richtlinie zum Verwerfen / Entfernen wie NumPy. Lange Zeit bei 0.x zu sein, bedeutet nicht semver.

derjenige, der (wie ich es sehe) der dominierende im wissenschaftlichen Rechnen ist

Traditionelle Vergleiche des SciPy-Ökosystems finden sich mit Dingen wie Matlab und R. Ich kann keine Informationen über R finden, aber es ist bei 3.x und hat sich stark weiterentwickelt, also wahrscheinlich nicht semver. Matlab: definitiv nicht semver.

RE: Phantasie Indizierung. In der Tat könnte dies eine dedizierte Funktion verwenden. Dies wurde beispielsweise in TensorFlow mit tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask usw. durchgeführt. Das Ergebnis ist etwas ausführlicher als Überladen von [] , aber sicherlich transparenter.

Ein weiteres Feature, das helfen kann, sind Typanmerkungen, ein Feature, das teilweise durch die Schwierigkeit des Übergangs von Python 2 zu 3 motiviert war.

Ich sage nicht, dass das einfach wäre. In meinen Augen sind die Konsequenzen für die Gemeinschaft eine größere Sache. Dies würde in der Tat viel Energie erfordern, um Projekte wie SciPy umzusetzen und anschließend in Projekte umzuwandeln.

@khinsen Ich habe die Diskussion die ganze Woche verfolgt und ich glaube, ich habe ein praktisches Testproblem, um Ihre

Derzeit ist dank des Apple Accelerate-Frameworks die mindestens erforderliche LAPACK-Version 3.1.ish, die aus mehr als einem Jahrzehnt stammt. Und derzeit ist LAPACK bei 3.8.0. In der Zwischenzeit haben sie eine ganze Reihe von Routinen verworfen (veraltet und / oder entfernt) und viele Fehler behoben und vor allem neue Routinen eingeführt, die erforderlich sind, um die Lücke zwischen kommerzieller Software und wissenschaftlicher Python-Software zu schließen. Das Endergebnis ist hier zusammengefasst . Ich habe in den letzten 6 Monaten hauptsächlich @rgommers und andere nervt. Und ich kann Ihnen versichern, wenn sie die Art von Menschen waren, die Sie, vielleicht unfreiwillig, hier porträtiert haben, sollte dies inzwischen geschehen sein und den Code vieler gebrochen haben Menschen. Stattdessen haben sie geduldig erklärt, warum es nicht so einfach ist, die Unterstützung für Accelerate einzustellen.

Jetzt besteht ein unbestrittener Bedarf an neueren Versionen. Das ist nicht die Diskussion und wir können diesen Teil sicher überspringen. Es gibt einen erheblichen Teil der Benutzer von NumPy und SciPy, die davon profitieren würden. Aber wir können es nicht einfach wegen der Argumente fallen lassen, die Sie bereits vorgebracht haben. Wie würden Sie das lösen?

Ich frage das nicht auf eine snarky Art und Weise, aber da alle Entwickler scheinbar gleich denken (und ich muss sagen, dass ich ihnen zustimme), kann Ihr Look vielleicht eine neue Idee geben. Sollten wir Accelerate beibehalten und jedes Mal ein neues NumPy / SciPy-Paket erstellen, wenn so etwas passiert? Wenn wir den Support einstellen, um Innovationen zu entwickeln, was ist Ihrer Meinung nach der beste Weg, um hierher zu kommen?

Derzeit ist dank des Apple Accelerate-Frameworks die mindestens erforderliche LAPACK-Version 3.1.ish

@mhvk , dies könnte ein Problem für # 9976 in 1,14 sein, das meiner Meinung nach 3.2.2 benötigt (Bearbeiten: Lassen Sie uns die Diskussion dorthin verschieben)

@xoviat : Lassen Sie uns diese Diskussion zu diesem Thema haben

@ilayn Danke, dass du diese Diskussion konkret und konstruktiv

Der wichtigste gemeinsame Punkt: Es gibt verschiedene Benutzer / Communities mit unterschiedlichen Anforderungen. Einige möchten beschleunigen, andere möchten die neuen LAPACK-Funktionen. Beide haben gute Gründe für ihre spezifischen Prioritäten. Es kann sogar Leute geben, die sowohl Accelerate als auch die neuen LAPACK-Funktionen möchten, obwohl mir dies nicht klar ist.

In der Fortran / C-Welt gibt es kein solches Problem, da die Software-Stacks flacher sind. Es gibt Fortran, LAPACK und den Anwendungscode ohne zusätzliche Zwischenprodukte. Was passiert ist, dass jeder Anwendungscode abhängig von seinen Prioritäten eine bestimmte Version von LAPACK auswählt. Rechenzentren halten normalerweise mehrere LAPACK-Versionen parallel, jede in einem eigenen Verzeichnis. Die Auswahl erfolgt durch Ändern des Makefile des Anwendungscodes.

Die Lehre, die wir in das SciPy-Ökosystem übernehmen können und sollten, ist, dass die Auswahl von Softwareversionen nicht Aufgabe der Softwareentwickler ist, sondern der Personen, die anwendungsspezifische Softwarepakete zusammenstellen. In unserer Welt sind dies die Leute, die an Anaconda, Debian und anderen Software-Distributionen arbeiten, aber auch Systemmanager auf verschiedenen Ebenen und Endbenutzer mit der richtigen Kompetenz und Motivation.

Mein Vorschlag für das SciPy / LAPACK-Dilemma ist daher, das heutige SciPy mit Accelerate beizubehalten, es jedoch in den minimalen Wartungsmodus zu versetzen (möglicherweise von verschiedenen Personen übernommen). Leute, die beschleunigen möchten, können dann "SciPy 2017" wählen und glücklich sein. Sie werden die neuen LAPACK-Funktionen nicht erhalten, aber vermutlich ist das für die meisten von ihnen in Ordnung. Die Entwicklung wird in einem neuen Namespace fortgesetzt ( scipy2 , scipy2018 oder was auch immer), der auf modernes LAPACK umschaltet. Wenn technisch möglich, erlauben Sie die parallele Installation dieser beiden (und zukünftigen) Varianten (was meiner Meinung nach für SciPy möglich sein sollte). Andernfalls müssen Personen, die beide benötigen, mehrere Umgebungen verwenden (conda, venv oder systemweite Umgebungen über Nix oder Guix). Beachten Sie, dass ich auch in diesem zweiten Szenario dringend empfehle, den Namespace bei jeder inkompatiblen Änderung zu ändern, um sicherzustellen, dass Leser von Python-Code auf jeder Ebene verstehen, für welche SciPy-Version der Code geschrieben wurde.

Die Grundidee ist, dass Entwickler neue Inhalte vorschlagen (und sich auf deren Entwicklung konzentrieren), diese jedoch nicht allgemein als "besser" oder als universellen Ersatz bewerben. Die Wahl der richtigen Kombination von Softwareversionen für eine bestimmte Aufgabe ist nicht ihre Aufgabe, sondern die eines anderen.

Die allgemeine Idee, dass Entwicklung und Montage unabhängig und von verschiedenen Personen durchgeführt werden, legt auch nahe, dass die heutigen Megapakete in kleinere Einheiten aufgeteilt werden sollten, die unterschiedlich schnell voranschreiten können. Es gibt heute keinen Grund für NumPy, das eine kleine LAPACK-Oberfläche und Tools wie f2py . Für SciPy mag es sinnvoll sein, einen gemeinsamen Namespace zu haben, der auf Kohärenz und eine gemeinsame Entwicklungsrichtlinie hinweist, aber die Unterpakete könnten durchaus unabhängig voneinander verteilt werden. Der Mega-Paket-Ansatz geht auf Pythons Motto "Batterien inklusive" zurück, das vor 20 Jahren großartig war. Die heutige Benutzerbasis ist dafür zu vielfältig, und Softwareverpackungen wurden allgemein als eigenständige Aktivität anerkannt. Das Einschließen der Batterien sollte nun Anacondas Aufgabe sein.

Das Haupthindernis für einen solchen Ansatz sind traditionelle Linux-Distributionen wie Debian oder Fedora mit ihrem Ansatz "Eine Python-Installation pro Maschine". Ich denke, sie könnten mit angemessenem Aufwand zu mehreren systemweiten virtuellen Umgebungen wechseln, aber ich habe nicht viel darüber nachgedacht. Die Zukunft der Softwareverpackung sind für mich umweltbasierte Systeme wie Conda oder Guix.

Ich sehe nicht, wie alle Präpositionen, die Sie bisher aufgestellt haben, mit einem dieser Schritte kompatibel sind

• Sie haben gerade den Wahnsinn des folgenden Bildes nachgebildet
  
  Gerade gezählt und ich habe jetzt 27 Kopien auf meinem Windows-Computer. Multiplizieren Sie dies nun mit 10 seit (Releases sind hier häufiger) und mit 2 (da NumPy- und SciPy-Release-Zyklen unabhängig sind). Im Jahr 2025 werde ich leicht 15 Kopien jeder Bibliothek und 10 LAPACKs und 5 f2pys als Abhängigkeiten haben. Ganz zu schweigen von der Wartungslast von nur einem Dutzend Personen in beiden Paketen, dies wird einfach nicht funktionieren. (C ++ ist nicht relevant, fügen Sie eine Standardbibliothek von irgendetwas ein). Fragen Sie einen kommerziellen Codeentwickler nach Win und sagen Sie ihm, dass dies eine so gute Idee ist. Ich bin nicht verantwortlich für das, was in diesem Austausch folgt.
• Dann haben Sie die Granularität der Pakete erhöht und jetzt alle Dinge alleine mit verschiedenen Paketversionen erledigt. f2py hat in einer Version etwas kaputt gemacht, sodass SciPy in der nächsten nicht mehr erstellt, aber immer noch von der früheren Version von NumPy abhängt. Eine ganzheitliche Einheit sollte sie also kostenlos zusammenbringen.
• Dann haben Sie auch Anaconda (oder ein anderes Unternehmen) zu einem Unternehmen mit großer Abhängigkeit gemacht, genau wie Accelerate. Oder es wird einfach eine Fülle von "jemand anderem" geben.
• Dann haben Sie den größten Teil der Benutzerbasis in einen Workflow mobilisiert, den sie wirklich nicht wollen (ich selbst eingeschlossen), der virtuelle Umgebungen umfasst.
• Dann haben Sie im Vorbeigehen sogar Linux-Betriebssysteme geändert (was bedeutet ... ich meine, lesen Sie einfach einige ihrer Mailinglisten, es macht Spaß).

Vielleicht hast du ein bisschen abgeschweift.

(Dies ist zu einer für alle freien Diskussion geworden, also werde ich weitermachen und einspringen).

Das Problem bei der Beibehaltung der Unterstützung für die Beschleunigung besteht nicht darin, dass neuere LAPACK-APIs fehlen. Wenn das das Problem wäre, könnten wir neuere LAPACK-Unterlegscheiben versenden und fertig sein. Das Problem ist, dass es grundlegende Funktionen gibt, die in bestimmten Szenarien falsche Ergebnisse zurückgeben. Es gibt keine andere Möglichkeit, dies zu umgehen, als unsere eigenen BLAS-Funktionen zu schreiben. Und wenn wir das tun, könnten wir genauso gut OpenBLAS oder MKL benötigen.

@xoviat Diese wurden alle unter https://github.com/scipy/scipy/pull/6051 besprochen

@ilayn Ja, ich bin mir sicher, dass ich bereits über die Punkte Bescheid weiß, die ich mache. Aber der Kommentar war für @khinsen; Ich denke, er hat den Eindruck, dass wir die Unterstützung von Accelerate tatsächlich beibehalten können.

Man könnte argumentieren, dass eine Funktion (oder Einschränkung) des Python-Ökosystems darin besteht, dass Sie eine Version einer Bibliothek ohne den schrecklichen Hack der Namensverfälschung erhalten. Dies geschieht in Core Python. Aus diesem Grund gibt es Bibliotheken mit den Namen _lib_ und _lib_ 2 , die denselben Zweck haben, jedoch API-Unterschiede aufweisen. Sogar Erzpython funktioniert so. Es ist unmöglich, Standardbibliotheken über Versionen hinweg zu mischen, selbst wenn beide auf dem modernen Python technisch verwendbar sind, ohne dass jemand sie rippt und auf PyPi stellt. Es gibt viele Fragen zu

@ilayn Wenn Sie aus irgendeinem Grund alle möglichen Kombinationen aller Versionen von allem auf Ihrem Computer haben möchten, ja, das ist ein Chaos. Aber warum willst du das? Wenn Sie sich auf die Kombinationen beschränken, die Sie tatsächlich für Ihre Anwendungsszenarien benötigen, wird es bestimmt weniger. Als Beispiel behalte ich genau zwei Python-Umgebungen auf meinem Computer: eine mit Python 2 + NumPy 1.8.2 zum Ausführen meines 20 Jahre alten Codes und eine, die den Stand der Technik von vor ungefähr zwei Jahren für alles andere darstellt ( vor zwei Jahren, weil ich es vor zwei Jahren eingerichtet habe und danach keinen Grund mehr für ein Upgrade gesehen habe).

Was die Granularität betrifft, war mir mein Vorschlag vielleicht nicht ganz klar. Was ich befürworte, ist mehr Granularität in der Verpackung, nicht in der Entwicklung. Ich würde erwarten, dass die Entwicklung von beispielsweise f2py und SciPy in enger Abstimmung fortgesetzt wird. f2py-2018 und SciPy-2018 sollten zusammenarbeiten. Das bedeutet nicht, dass sie als eine Einheit gepackt werden müssen. Ziel ist es, Software-Distributionsmanagern mehr Freiheit bei ihrer Arbeit zu bieten.

Ich möchte Anaconda oder eine andere Distribution definitiv nicht abhängig machen. Es ist eher wie die "Fülle von jemand anderem", obwohl ich nicht erwarte, dass die Anzahl der Distributionen auf "Fülle" ansteigt, da das Zusammenstellen eine Menge Arbeit ist.

Ich habe keine Ahnung, welchen Workflow "die Benutzerbasis" will. Ich sehe viele verschiedene Benutzerbasen mit unterschiedlichen Anforderungen. Persönlich würde ich mich für mehrere Umgebungen entscheiden, aber wenn es eine bedeutende Benutzerbasis gibt, die eine einzige Umgebung pro Computer wünscht, wird sich eine gewisse Distribution darum kümmern. Virtuelle Umgebungen wurden jedoch aus einem bestimmten Grund erfunden. Sie lösen ein echtes Problem. Distributionen auf Systemebene wie Nix oder Guix bringen sie auf eine andere Ebene. Ich erwarte nicht, dass sie weggehen.

Übrigens folge ich tatsächlich der Mailingliste einer Linux-Distribution (Guix). Nicht viel Spaß, aber viel bodenständige Grunzarbeit. Ich bin froh, dass es Leute gibt, die das tun.

@xoviat Ich habe nicht vorgeschlagen, "Accelerate-Support

Es geht wirklich nur um Kennzeichnung und Kommunikation. Ich möchte mich vom idealisierten Image der Software auf einem linearen Weg des Fortschritts entfernen, wobei neuere Versionen "besser" sind, wie durch "höhere" Versionsnummern angezeigt. Ich möchte dieses Bild durch ein Bild ersetzen, das ich für realistischer halte: Es gibt keine offensichtliche Ordnungsbeziehung zwischen Softwareversionen. Diejenigen, die von einer langlebigen kohärenten Entwicklergemeinschaft erstellt wurden, haben eine zeitliche Reihenfolge, aber das bedeutet nichts über Qualität oder Eignung für eine bestimmte Anwendung.

Wenn das idealisierte Bild richtig wäre, würden wir keine Gabeln sehen und wir hätten keine virtuellen Umgebungen. Auch Projekte wie VersionClimber .

Was ich vorschlage, ist, dass Softwareentwickler diese Realität annehmen sollten, anstatt sie zu leugnen. Sie sollten ihre Produkte für eine Welt der Vielfalt entwickeln (und vor allem verpacken und kennzeichnen).

@khinsen Wenn Sie mit falschen Ergebnissen aus linearen Algebra-Funktionen Und selbst wenn Sie es nicht sind, was passiert, wenn jemand auf der Straße SciPy für ein Problem mit dem Beschleunigen verantwortlich macht? Was passiert, wenn jemand seinen Kuchen haben und ihn auch essen möchte? Ich kann nur sehen, dass das passiert.

@ xoviat Nein, ich bin mit falschen Ergebnissen von linearen Algebra-Funktionen nicht

In gewisser Weise ist dies Teil des Megapaketproblems. Mit einer detaillierteren Verteilung wäre es einfacher, das Material auszuwählen, das sowohl auf Entwicklungs- als auch auf Verteilungsbaugruppenebene funktioniert. Man könnte sich sogar einen Distributionsassembler vorstellen, der eine domänen- und plattformspezifische SciPy-Distribution erstellt, in der verschiedene Unterpakete unterschiedliche LAPACK-Versionen verwenden, z. B. zur Verwendung in HPC-Kontexten.

Ich bin mir jedoch sicher, dass es viele SciPy-Benutzer gibt, die die betroffenen Funktionen überhaupt nicht benötigen.

Es gibt nur minimale Beweise für diese Aussage und ich würde tatsächlich auf das Gegenteil wetten. Die Funktionen sind weit verbreitet, schlagen jedoch nur in bestimmten Szenarien fehl. Mit anderen Worten, Ihre Ergebnisse sind wahrscheinlich korrekt, aber möglicherweise nicht korrekt. Ja, dies gilt wahrscheinlich für den SciPy, den Sie derzeit installiert haben, wenn Sie OSX verwenden. Ja, das muss behoben werden.

Was die Pflege eines separaten Zweigs angeht, glaube ich nicht, dass irgendjemand dagegen wäre, Ihnen Schreibzugriff auf einen bestimmten Zweig zu gewähren, damit Sie ihn pflegen können. Dies ist jedoch Open-Source-Software, und die Leute arbeiten an dem, was sie wollen. Ich bin skeptisch, dass viele Menschen daran interessiert wären, diesen Zweig aufrechtzuerhalten.

Eigentlich denke ich, dass die Anaconda SciPy mit MKL kompiliert wurde, so dass Sie in diesem Fall nicht betroffen wären. Aber warum sollten Sie dann die Unterstützung beschleunigen?

@xoviat Es scheint, dass es hier ein großes Missverständnis gibt. Ich habe überhaupt keine persönlichen Interessen in dieser speziellen Ausgabe. Ich verwende keine linearen Algebra-Routinen von SciPy.

Sie haben auf einen Thread zu einem SciPy-Problem verwiesen und gefragt, wie ich mit dieser Situation umgehen würde. Der Thread zeigt deutlich die Zurückhaltung, die Accelerate-Unterstützung einfach einzustellen, woraus ich schließen konnte, dass es eine signifikante Benutzergruppe gibt, die von einer solchen Änderung betroffen wäre. Wenn diese Benutzergruppe nicht existiert, wo liegt dann das Problem? Warum hat SciPy die Accelerate-Unterstützung nicht bereits eingestellt?

@xoviat Die Pflege eines separaten Zweigs ist für jedermann einfach. Es ist nicht erforderlich, dass es im selben GitHub-Repository gehostet wird. Mit anderen Worten, Zweige sind nicht das Problem. Das Problem ist der Namespace, um die parallele Existenz separater SciPy-Versionen für Benutzer (und Distributionsassembler) transparent zu machen.

Wenn Sie heute den Code "scipy importieren" sehen, wissen Sie nicht, für welchen Bereich von SciPy-Versionen er funktionieren soll (dh bis zu einem gewissen Grad getestet wurde). Im besten Fall gibt es eine README-Datei mit der Aufschrift "SciPy> = 0.8" oder so ähnlich. Diese Gewohnheit basiert auf der Annahme, dass "höhere" Versionen immer "besser" sind und niemals etwas verschlechtern (brechen, verlangsamen, ...). Und diese Annahme ist ganz einfach falsch.

Wenn andererseits der Code "scipy2017 als scipy importieren" lautet, ist jedem Leser klar, dass die Verwendung mit früheren oder späteren Versionen zu bösen Überraschungen führen kann. Und wenn alte SciPy-Versionen verschwinden (effektiv aus Mangel an Wartung), schlägt ein solcher Code mit einer Fehlermeldung fehl und funktioniert nicht mehr unzuverlässig.

Dies ist der einzige Punkt, den ich in diesem Thread ansprechen möchte. Die Koexistenz verschiedener Versionen ist Realität. Die Idee, dass höher besser ist, ist ein Traum. Lassen Sie uns realistisch sein und uns für die reale Welt organisieren, indem wir ein Universum mit mehreren Versionen anerkennen und die Kommunikation aller anpassen, um Missverständnissen vorzubeugen.

Nun, keine Ahnung ... meiner Meinung nach ist ein bestimmter Versionsimport keine Warnung, wenn es um Warnungen geht. Es ist verboten, eine andere Version zu verwenden, da die Benutzer, die Probleme haben, wie Sie es beschreiben, es nicht wagen werden, Ihren Code zu ändern. Eine Warnung wäre, wenn Sie bei der Installation / Laufzeit eine Warnung drucken, dass sie für alle außer bestimmten Numpy-Versionen nicht getestet wurde.

Ich nehme an, dass das Erstellen dieser Art von zusätzlichen Paketen möglich ist. Ich erwarte auch, dass es nur eine andere Art von Hölle schaffen wird. Vieles könnte überleben, aber die Typprüfung zum Beispiel wird und kann nicht, wenn Sie zwei Versionen mischen. Sie werden also im Grunde nicht wissen, ob es funktionieren kann oder nicht, bis Sie es versuchen (und niemand wird dies testen!).
Und wenn Sie nicht vorschlagen, zwei Versionen zu mischen, wird Ihre scipy2017-Lösung die Sache nur noch schlimmer machen. Scheint eher so, als würden wir so etwas wie eine dynamische / virtuelle Laufzeitumgebung benötigen (wie pin_import_version("1.6<numpy<1.10", level="raise") vor jedem Import auf Python-Ebene).

Der spezifische Import ist sinnvoll, wenn Sie größere unzulässige Änderungen haben (ein bisschen wie py2 / py3), und wir haben bereits gesehen, dass wir unterschiedliche Meinungen darüber haben, wo oder auf welcher Zeitskala diese "große" Linie zu sein scheint.

Die Abwärtskompatibilität NEP # 11596 wurde übermittelt. Können wir dies schließen?

Die Abwärtskompatibilität NEP # 11596 wurde übermittelt. Können wir dies schließen?

Ja, wir können das schließen. Unabhängig von dieser NEP (in der Semver ausdrücklich als abgelehnte Alternative erwähnt wird) besteht der Konsens der Kernentwickler darin, dass wir nicht zu Semver wechseln möchten. Daher als Wontfix schließen.

Vielen Dank für die Diskussion an alle.