Numpy: "Kontrollierte" Erstellung von Objektarrays

Eine Möglichkeit wäre
```python
Versuchen:
# dem Spiel einen Schritt voraus sein und die Einstellung zu einem Fehler hochstufen, der sie ersetzt
mit warnings.catch_warnings():
warnings.filterwarnings('raise', DeprecationWarning, message="...")
c_arr = np.asarray(c)
außer (DeprecationWarning, ValueError):
# was immer Sie derzeit für ValueError tun

Ich denke, dies und der in gh-15045 erwähnte fehlgeschlagene Test sind Fälle, in denen das Ausgeben eines DeprecationWarning für ein paar Jahre anstelle des direkten Sendens eines ValueError zu mehr Code-Curn als nötig führt.

Beachten Sie, dass warnings.catch_warnings nicht threadsicher ist. Das macht die Problemumgehung etwas anfällig für Folgeprobleme auf der ganzen Linie.

Ich denke, dass der Code-Churn die Deprecation-Periode wert ist.

Matplotlib führt seine Testsuite mit Warnungen als Fehler aus, um genau diese Art von Änderung frühzeitig zu erkennen, daher scheint mir das System zu funktionieren :).

Aber AFAICT gibt es nicht einmal eine einigermaßen einfache Lösung (wie oben erwähnt, ist die vorgeschlagene Korrektur nicht threadsicher) dafür :/

Ich glaube, ich verstehe hier den Punkt von

Das Problem ist, dass der Bibliotheksautor heute keine Möglichkeit hat, zu fragen, "würde dies eine Warnung ausgeben", ohne tatsächlich ... die Warnung auszugeben, und deren Unterdrückung ist nicht threadsicher.

Zur Sicherheit von Warnthreads :

AFAIK, die veraltete Version befindet sich im Release-Zweig. Wollen wir es rückgängig machen? Wenn nicht, benötigen die Fixes Backports. Mir ist immer noch nicht klar, warum die Warnungen in den Release-Zweigrädern nicht ausgelöst wurden und bis zu den letzten beiden Builds in den nächtlichen Builds nicht auftauchten. Ich habe nach dem Branch nichts geändert und nichts sieht in den Commits seitdem im Master-Branch sehr verdächtig aus, außer möglicherweise #15040.

IMHO (und in Übereinstimmung mit dem obigen Punkt von

Oder möglicherweise behandelt Multibuild Branches anders als Master.

FWIW Ich war bei dieser Änderung immer mindestens -1, besonders als begeisterter Benutzer von zerlumpten Datenstrukturen, aber jetzt muss ich sowieso herausfinden, was ich mit den Hunderten von Testfehlern für die Vorbereitung von SciPy 1.4.0rc2 tun kann https://github.com/scipy/scipy/pull/11161

Jetzt muss ich herausfinden, was ich gegen die Hunderte von Testfehlern tun kann

Eine einfache Möglichkeit wäre:

• Unterdrücken Sie die Warnung in Ihrer pytest-Konfiguration
• Öffnen Sie ein Problem, um es später zu beheben

Der springende Punkt bei der Verwendung von DeprecationWarning anstelle von ValueError bestand darin, nachgelagerten Projekten und Benutzern eine Nachfrist zu geben, um genau das zu tun.

AFAIK, die veraltete Version befindet sich im Release-Zweig. Wollen wir es rückgängig machen?

Ich denke, das tun wir, es regnet Probleme. Wir haben jetzt eine Liste der Fehler in Pandas, Matplotlib, SciPy, in numpy.testing und NumPy ufuncs, == usw. Ich denke, wir sollten die Änderung jetzt rückgängig machen und alle diese untersuchen/reparieren Dinge, dann führen Sie die Veraltung wieder ein.

Können wir bei einer ausstehenden Veraltungswarnung Kompromisse eingehen?

Auf diese Weise können nachgelagerte Projekte es zu ihren Ignorierlisten hinzufügen, und wenn wir zurück zu DeprecationWarning wechseln, können sie die Entscheidung erneut treffen.

Wir scheinen vom ursprünglichen Problem abgewichen zu sein, das zu sein scheint: "Wie kann matplotlib bestimmen, ob es sich um eine einzelne Farbe oder eine Liste von Farben handelt?". Ich denke, es sollte eine Lösung geben, die das Umwandeln der Werte in ein Ndarray und das Überprüfen des Dtypes dieses Arrays nicht erfordert. Eine Art rekursive is_a_color() Funktion könnte eine bessere Lösung sein.

Ich habe die Änderung für 1.18.x in #15053 rückgängig gemacht.

Das Gefühl ist, dass das Brechen von Scipy und Pandas CI nervig genug ist, um es vorübergehend auch in Master zurückzusetzen. Ich möchte jedoch, dass es im Wesentlichen geplant (sagen wir innerhalb eines Monats) zurückkehrt. Möglicherweise müssen wir jedoch eine Lösung finden. Auch die Korrekturen, die Pandas machen, sind für mich etwas beunruhigend, da sie catch_warnings .

Wenn es wirklich keine Möglichkeit gibt und wir eine threadsichere Warnungsunterdrückung brauchen. np.seterr könnte möglicherweise einen Platz dafür freihalten :/.

Wir scheinen vom ursprünglichen Problem abgewichen zu sein, das zu sein scheint: "Wie kann matplotlib bestimmen, ob es sich um eine einzelne Farbe oder eine Liste von Farben handelt?".

Ich denke, das Problem, das @anntzer anspricht , ist jedoch allgemeiner. Es geht darum, eine Funktion zu schreiben, die viele Arten von Eingaben benötigt, mit Logik wie:

• ndarray(flexible_input) erstellen
• if `new_ndarray.dtype.kind == 'O': Behandeln Sie dies
• sonst: use_the_array

da man einem solchen Code nicht dtype=object hinzufügen kann, was ist zu tun?

Auch die Korrekturen, die Pandas machen, sind für mich etwas beunruhigend, da sie catch_warnings .

@seberg war dafür nicht suppress_warnings besser?

@rgommers nein, suppress_warnings das Problem gelöst, dass die Unterdrückung von Warnungen dauerhaft war, obwohl dies nicht der Fall sein sollte. Das wurde jedoch in neueren Python-Versionen behoben, sodass wir es nicht mehr wirklich brauchen (es hat bessere Eigenschaften, da es Verschachtelung unterstützt, aber es unterstützt keine Thread-Sicherheit. Ich bin mir nicht sicher, ob das außerhalb von Python möglich ist, und sogar wenn es so wäre, ist es wahrscheinlich nicht wünschenswert)

Ich bin mir nicht ganz sicher, ob die problematischen Fälle der ursprünglichen Absicht (https://numpy.org/neps/nep-0034.html) zuwiderlaufen, oder wir werden einfach nicht erwartet.

Wie auch immer, ein Ausweg wäre, das alte Verhalten im Sinne von "Ihr Anliegen zu schätzen, aber wir wollen explizit das kontextabhängige Objekt dtype explizit zu aktivieren und werden problematische Eingaben selbst behandeln". So etwas wie einer von

~~~
np.array(data, dtype='allow_object')

np.array(data, allow_object_dtype=True)

mit np.array_create_allow_object_dtype():
np.array(Daten)
~~~

alles nicht sehr hübsch und die Benennung sicher noch verbesserungswürdig. Aber das gibt Bibliotheken, die sich auf das Verhalten verlassen haben und es (zumindest im Moment) behalten wollen, einen sauberen Ausweg.

Ist der Matplotlib-Fall nicht tatsächlich:

with np.forbid_ragged_arrays_immediately():
    np.array(data)

da möchten Sie den Fehler wirklich abfangen, anstatt einen Objekt-Dtype zu erhalten?

Es gibt keine Rücknahme der Veraltung, die derzeit für den Master aussteht. Ich denke nicht, dass es wie in 1.18 en gros zurückgesetzt werden sollte, weil dadurch auch die Fixes entfernt wurden, die wir meiner Meinung nach beibehalten möchten. @mattip Eine gezieltere Reversion wäre wünschenswert, bis wir entscheiden, was langfristig zu tun ist.

FWIW Ich denke, die meisten Stellen in mpl, die dies treffen, können behoben werden (mit mehr oder weniger Umstrukturierung - in einem Fall stellt sich der Code heraus, wenn er danach viel schneller ist ...).
Ich denke , die vorgeschlagene API von @timhoffm wäre schöner als ein with np.forbid_ragged_arrays_immediately: da letzteres leicht in Bezug auf ersteres geschrieben werden kann (raise if np.array(..., allow_object=True).dtype == object ), während das Gegenteil ( try: with np.forbid: ... except ValueError: ... ) wäre weniger effizient, wenn wir doch noch ein Objektarray erstellen wollen. Aber ein CM (das sich nur "lokal über den Einstellungszeitraum hinaus bewegt") wäre besser als nichts.

(Auch hier finde ich die Änderung gut, es kommt nur darauf an, wie sie ausgeführt wird.)

Ja, wir müssen nur herausfinden, wie die API aussehen soll. Wie viele darauf hingewiesen haben, gibt es derzeit zwei Hauptprobleme:

1. Verwirrung von object und "allow ragged" . Wenn die Objekte einen vernünftigen Typ haben (sagen wir Decimal ), möchten Sie tatsächlich die Warnung/den Fehler erhalten, müssen aber möglicherweise auch dtype=object
2. Es gibt weder eine Möglichkeit, sich für das neue Verhalten zu entscheiden oder das alte (ohne Vorwarnung) weiter zu verwenden. Für die interne Nutzung scheint zumindest Opt-In notwendig zu sein, wenn wir es nicht bereitstellen, gehen wir grundsätzlich davon aus, dass (evtl. indirekt) nur Endverbraucher in diese Fälle geraten?

Schließlich müssen wir herausfinden, wie wir es in unseren Code stopfen können :). ndmin kann ein weiteres Ziel sein, um Flags einzustopfen, die zumindest das zerlumpte Verhalten kontrollieren.

Es gibt keine Rücknahme der Veraltung, die derzeit für den Master aussteht. Ich denke nicht, dass es wie in 1.18 en gros zurückgesetzt werden sollte, weil dadurch auch die Fixes entfernt wurden, die wir meiner Meinung nach beibehalten möchten. @mattip Eine gezieltere Reversion wäre wünschenswert, bis wir entscheiden, was langfristig zu tun ist.

Ich sehe kein Problem mit einem vollständigen Zurücksetzen und dann wieder einführen aller Teile, die jetzt Sinn machen. Nochmals, etwas rückgängig zu machen ist kein Werturteil darüber, was gut oder schlecht ist, es ist nur ein pragmatischer Weg, um eine Menge Dinge aufzulösen, die wir gerade durch Drücken der Zusammenführungstaste kaputt gemacht haben. Es gibt eindeutig Auswirkungen und ungelöste Probleme, die in der NEP nicht vorhergesehen wurden, daher ist es richtig, zuerst umzukehren.

Ein Argument dafür, noch nicht zurückzusetzen – während die Änderung im Master erfolgt, können wir nachgelagerte CI-Läufe nutzen, um herauszufinden, wie ihre Problemumgehungen aussehen würden

Downstream-CI ist rot, das ist _sehr_ nicht hilfreich. Wir haben jetzt ihre Fehlerliste, wir müssen ihre CIs nicht rot halten, um unser Leben hier ein wenig einfacher zu machen.

Und zumindest läuft die CI von Matplotlib gegen pip install --pre nicht gegen den Master-Zweig

Und zumindest läuft die CI von Matplotlib gegen pip install --pre nicht gegen den Master-Zweig

Das ist das Ziehen von den nächtlichen Rädern, wie es aussieht. Die Änderung wurde bereits für 1.18.0rc1 rückgängig gemacht, Sie sollten sie also nicht sehen, wenn Sie mit --pre von PyPI installieren würden.

Einige der obigen Kommentare laufen darauf hinaus, die vorgeschlagenen Änderungen in NEP 34 zu überdenken. Ich bin mir nicht sicher, ob dieser Thread der geeignete Ort ist, um diese Diskussion fortzusetzen, aber hier geht es. (Es schadet nicht, wenn es an anderer Stelle diskutiert werden sollte - das Kopieren und Einfügen von Kommentaren ist einfach. :smile: Außerdem haben einige von Ihnen in einer Diskussion über Slack eine Variation dieser Kommentare gesehen.)

Nachdem ich kürzlich darüber nachgedacht hatte, hatte ich die gleiche Idee wie @timhoffms erster Vorschlag (und die Idee wurde wahrscheinlich in den letzten Monaten zu anderen Zeiten vorgeschlagen): Definiere ein bestimmtes String- oder Singleton-Objekt, das, wenn es als gegeben wird, Das Argument dtype für array ermöglicht es der Funktion, unregelmäßig geformte Eingaben zu verarbeiten, indem ein 1-d-Objektarray erstellt wird. Tatsächlich aktiviert dies das Verhalten von dtype=None vor NEP-34, bei dem unregelmäßig geformte Eingaben automatisch in ein Objektarray umgewandelt werden. Wenn ein anderer Wert für dtype angegeben wird (einschließlich None oder object ), wird eine veraltete Warnung ausgegeben, wenn die Eingabe unregelmäßig ist. In einer zukünftigen Version von NumPy wird diese Warnung in einen Fehler umgewandelt.

Ich denke, es ist jetzt klar, dass die Verwendung von dtype=object , um die Verarbeitung von unregelmäßig geformten Eingaben zu ermöglichen, keine gute Lösung für das Problem ist. Idealerweise entkoppeln wir die Begriffe "Objekt-Array" von "Zacken-Array". Aber wir können sie nicht vollständig entkoppeln, denn wenn wir mit einem unregelmäßigen Array umgehen wollen, haben wir nur die Wahl, ein Objektarray zu erstellen. Auf der anderen Seite möchten wir manchmal ein Objektarray, aber nicht die automatische Konvertierung von unregelmäßig geformten Eingaben in ein Objektarray von Sequenzen.

Angenommen, f1 , f2 , f3 und f4 sind Fraction (vgl. Punkt 1 in @sebergs letztem Kommentar). Fraction -Objekte, und ich arbeite mit Objektarrays von Fraction s. Ich bin nicht daran interessiert, ein zerlumptes Array zu erstellen. Wenn ich versehentlich a = np.array([f1, f2, [f3, f4]], dtype=object) schreibe, _möchte__ ich, dass ein Fehler generiert wird, aus all den Gründen, die wir NEP 34 haben. Mit NEP 34 wird das jedoch ein 1-d-Array der Länge 3 erzeugen.

Alternativen, die ein neues Schlüsselwortargument hinzufügen, wie der zweite Vorschlag von @timhoffm , erscheinen komplizierter als nötig. Das Problem, das wir zu lösen versuchen, ist die "Fußpistole", bei der unregelmäßige Eingaben automatisch in ein 1-d-Objektarray umgewandelt werden. Das Problem tritt nur auf, wenn dtype=None an array . Benutzer zu zwingen, dtype=None durch dtype=<special-value-that-enables-ragged-handling> zu ersetzen, um das alte lästige Verhalten beizubehalten, ist eine einfache Änderung an der API, die leicht zu erklären ist. Brauchen wir wirklich noch mehr?

Ich denke, es ist jetzt klar, dass die Verwendung von dtype=object , um die Verarbeitung von unregelmäßig geformten Eingaben zu ermöglichen, keine gute Lösung für das Problem ist. Idealerweise entkoppeln wir die Begriffe "Objekt-Array" von "Zacken-Array".

Klingt vielleicht vernünftig. Es ist auch gut, darauf hinzuweisen, dass es in NumPy kein echtes "Ragged Array"-Konzept gibt . Es ist etwas, das wir im Grunde nicht unterstützen (suchen Sie nach "zerlumpt" in den Dokumenten, im Issue-Tracker oder in der Mailingliste, um dies zu bestätigen, wenn Sie möchten), es ist etwas, das DyND und XND unterstützen, und wir haben nur begonnen, darüber zu sprechen, um es kurz zu machen "Wir möchten das np.array([1, [2, 3]]) Verhalten beseitigen, das Benutzer zum Stolpern bringt". Daher sollte das Backen in "ragged Arrays" als neue API-Sache mit äußerster Vorsicht erfolgen, es ist absolut nicht etwas, was wir fördern möchten. Es wäre also gut, dies bei der Benennung von dtype=some_workaround wir hinzufügen, deutlich zu machen.

Es scheint, dass sich die allgemeine Meinung um eine Lösung zur Erweiterung der Veraltung (möglicherweise auf unbestimmte Zeit) verdichtet, indem np.array(vals, dtype=special) wird, die sich wie vor NEP 34 verhalten. Ich bevorzuge einen Singleton anstelle eines Strings, da dies bedeutet, dass Bibliotheksverwendungen special = getattr(np.special, None) und ihr Code funktionieren versionenübergreifend.

Jetzt müssen wir uns für den Namen entscheiden und wo er veröffentlicht werden soll. Vielleicht never_fail oder guess_dimensions ? Was die Bereitstellung angeht, würde ich es vorziehen, es nicht an np zu hängen, sondern an ein anderes internes Modul, vielleicht mit einem _ um anzuzeigen, dass es sich wirklich um eine private Schnittstelle handelt.

Ich denke, der Weg nach vorn besteht darin, NEP 34 zu ändern und dann die Diskussion auf der Mailingliste zu veröffentlichen.

Beachten Sie, dass es auch einige Berichte über Probleme mit der Verwendung von Operatoren gab (zumindest == und operator.mod ). Schlagen Sie vor, das zu ignorieren oder diesen Zustand irgendwie im Array zu speichern?

In fast allen Fällen ist wahrscheinlich bekannt, dass einer der Operanden ein numpy-Array ist. Daher sollte es wahrscheinlich möglich sein, durch manuelles Konvertieren in ein numpy-Array ein gut definiertes Verhalten zu erzielen.

Könnte jemand auf das Beispiel operator.mod hinweisen?

Was den == Operator angeht, der, den ich gesehen habe, tat etwas wie np.array(vals, dtype=object) == vals wobei vals=[1, [2, 3]] (den Code umschreibend), also besteht die Lösung darin, das Array auf der rechten Seite proaktiv zu erstellen Seite.

Viele der Scipy-Fehler scheinen die Form np.array([0.25, np.array([0.3])]) , wobei das Mischen von Skalaren und Ndarray mit shape==(1,) mit der Dimensionserkennung in Konflikt gerät und ein Objektarray erzeugt. xref gh-15075

Könnte jemand auf das Beispiel operator.mod hinweisen?

Habe das in operator.mod mehr zu sehen).

Was den == Operator betrifft, der, den ich gesehen habe, tat etwas wie np.array(vals, dtype=object) == vals wobei vals=[1, [2, 3]] (den Code paraphrasieren), also besteht die Lösung darin, das Array auf der rechten Seite proaktiv zu erstellen Seite.

An diesem Punkt wird es np.array(vals, dtype=object) == np.array(vals, dtype=object) , also lösche den Test besser einfach :)

@mattip schrieb:

Ich bevorzuge einen Singleton anstelle eines Strings, da dies bedeutet, dass Bibliotheksverwendungen special = getattr(np.special, None) ausführen können und ihr Code versionenübergreifend funktioniert.

Das klingt für mich in Ordnung.

Jetzt müssen wir uns für den Namen entscheiden und wo er veröffentlicht werden soll. Vielleicht never_fail oder guess_dimensions ? Was die Bereitstellung angeht, würde ich es vorziehen, es nicht an np zu hängen, sondern an ein anderes internes Modul, möglicherweise mit einem _, um anzuzeigen, dass es sich wirklich um eine private Schnittstelle handelt.

Mein derzeitiger Arbeitsname dafür ist legacy_auto_dtype , aber es gibt wahrscheinlich viele andere Namen, über die ich mich nicht beschweren würde.

Ich bin mir nicht sicher, ob der Name privat sein sollte. Nach jeder praktischen Definition von _private_ und _public_ ist dies ein _öffentliches_ Objekt. Es bietet Benutzern die Möglichkeit, das alte Verhalten von beispielsweise array(data) beizubehalten, indem es in array(data, dtype=legacy_auto_dtype) . Ich kann mir vorstellen, dass die aktualisierte NEP erklären wird, wie Code auf diese Weise modifiziert werden sollte, um das Legacy-Verhalten beizubehalten (für diejenigen, die dies tun müssen). Wenn dies der Fall ist, ist das Objekt definitiv nicht privat. Tatsächlich scheint es sich um ein öffentliches Objekt zu handeln, das auf unbestimmte Zeit in NumPy verbleiben wird. Aber vielleicht ist mein Verständnis, wie sich die modifizierte NEP 34 entwickeln wird, falsch.

Einverstanden mit @WarrenWeckessers Beschreibung von öffentlich/privat; Entweder ist es öffentlich oder es sollte von niemandem außerhalb von NumPy verwendet werden.

Umbenennung: Bitte wählen Sie einen Namen, der die Funktionalität beschreibt. Dinge wie "Legacy" sind fast nie eine gute Idee.

Bitte wählen Sie einen Namen, der die Funktionalität beschreibt.

auto_object , auto_dtype , auto ?

Ein bisschen laut nachdenken...

Was macht dieses Objekt?

Wenn NumPy derzeit ein Python-Objekt erhält, das Teilsequenzen enthält, deren Längen nicht mit einem regulären nd-Array übereinstimmen, erstellt NumPy ein Array mit dem Datentyp object mit den Objekten auf der ersten Ebene, auf der die Forminkonsistenz auftritt als Python-Objekte hinterlassen. Beispiel: array([[1, 2], [1, 2, 3]]) hat die Form (2,) , np.array([[1, 2], [3, [99]]]) hat die Form (2, 2) usw. Mit NEP 34 verwerfen wir dieses Verhalten und versuchen daher, eine Array mit "ragged" Eingabe führt schließlich zu einem Fehler, es sei denn, es ist explizit aktiviert. Der besondere Wert, über den wir sprechen, ermöglicht das alte Verhalten.

Was ist ein guter Name für das? ragged_as_object ? inconsistent_shapes_as_object ?

An diesem Punkt wird es zu np.array(vals, dtype=object) == np.array(vals, dtype=object) , also lösche den Test besser einfach :)

Nun, ich habe paraphrasiert. Der eigentliche Test ist eher so, dass aus my_func(vals) == vals my_func(vals) == np.array(vals, dtype=object)

Ich werde eine Erweiterung von NEP 34 vorschlagen, um einen speziellen Wert für dtype zuzulassen.

Beachten Sie, dass scipy diesen Wächter anscheinend nicht benötigt, um Tests mit scipy/scipy#11310 und scipy/scipy#11308 zu bestehen

gh-15119 wurde fusioniert, wodurch die NEP neu implementiert wurde. Wenn es nicht zurückgesetzt wird, können wir dieses Problem schließen

Ich werde dies schließen, da wir es vor der Veröffentlichung von 1.19 nicht weiterverfolgt haben. Und ich hoffe zumindest, dass der Grund dafür darin lag, dass die Diskussion nachgelassen hat, da alle Großprojekte vernünftige Lösungen für die damit geschaffenen Probleme finden konnten.
Bitte korrigiert mich, wenn ich falsch liege, insbesondere wenn dies immer noch anfällig für Probleme mit Pandas, Matplotlib usw. ist. Aber ich gehe davon aus, dass wir davon während des Release Candidate-Zyklus 1.19.x gehört haben.