Numpy: Geben Sie hinting / annotation (PEP 484) für ndarray, dtype und ufunc ein

Erstellt am 2. März 2016  ·  70Kommentare  ·  Quelle: numpy/numpy

Funktionsanforderung: Organische Unterstützung für PEP 484 mit Numpy-Datenstrukturen.

Hat jemand einen Typhinweis für die bestimmte numpy.ndarray-Klasse implementiert?

Im Moment benutze ich das Tippen. Ja, aber es wäre schön, etwas Spezifischeres zu haben.

Zum Beispiel, wenn die numpy-Leute einen Typ-Alias ​​für ihre array_like-Objektklasse hinzugefügt haben. Besser noch, implementieren Sie die Unterstützung auf dtype-Ebene, damit andere Objekte sowie ufunc unterstützt werden.

ursprüngliche SO-Frage

01 - Enhancement static typing

Hilfreichster Kommentar

Ich wollte dies noch einmal durchgehen, um zu sehen, ob die Diskussionen fortgeschritten sind, insbesondere in Bezug auf typinformierende Forminformationen, die in vielen meiner Anwendungen besonders nützlich wären. Gibt es einen Status-Tracker oder ist dieser nicht hoch genug, um Ressourcen dafür bereitzustellen?

Alle 70 Kommentare

Ich glaube nicht, dass jemand darüber nachgedacht hat. Vielleicht möchten Sie? :-)

Ich werde auch vorschlagen, dass wir das gh-Problem schließen und die Diskussion auf die Mailingliste verschieben, wenn Sie dies weiterverfolgen möchten, da es besser für offene Designdiskussionen geeignet ist.

Nachdem ich diese Antwort auf SO erhalten habe, habe ich beschlossen, das Problem zu schließen.

Um es klar auszudrücken, wir haben eigentlich nichts dagegen, coole neue Python-Funktionen oder ähnliches zu unterstützen (eher das Gegenteil). Es ist nur so, dass wir ein freiwilliges Projekt ohne viele Ressourcen sind, also passiert etwas nur, wenn jemand, der interessiert ist, sich dafür einsetzt.

Die Mailingliste ist normalerweise der beste Ort, wenn Sie versuchen, an etwas zu arbeiten oder andere interessierte Leute für Ihre Hilfe gewinnen möchten.

Danke, @njsmith. Ich habe mich entschieden, hier zu beginnen, weil die Problemverfolgung geordneter ist als bei einer unstrukturierten Mailingliste (ich habe unter anderem nach einem Tag "Feature Request" gesucht ...).

Da der Typ, der mir auf SO geantwortet hat, mit einer tragfähigen Lösung zu mir zurückkam, beschloss ich, die Angelegenheit zu verlassen.
Möglicherweise sollte die Numpy-Dokumentation aktualisiert werden, um seine Antwort aufzunehmen (bitte geben Sie ihm in diesem Fall die Ehre).

Danke noch einmal!

Hallo Leute! Ich habe mich nur freundlich gefragt, ob in dieser Frage Fortschritte erzielt wurden. Vielen Dank.

Es gibt einige Diskussionen darüber auf der Mailingliste hier .

Ich öffne diese Ausgabe erneut für diejenigen, die daran interessiert sind, sie weiter zu diskutieren.

Ich denke, dass dies für NumPy sicherlich wünschenswert wäre, aber es gibt tatsächlich einige knifflige Aspekte der NumPy-API, die zum Sortieren eingegeben werden müssen, z. B. wie NumPy derzeit beliebige Objekte im Konstruktor np.array akzeptiert (obwohl wir dies möchten) Bereinigen Sie dies, siehe https://github.com/numpy/numpy/issues/5353).

Hier wird gute Arbeit geleistet: https://github.com/machinalis/mypy-data

Es wird diskutiert, ob die Arbeit stromaufwärts auf numpy oder typisiert verschoben werden soll: https://github.com/machinalis/mypy-data/issues/16

CC @mrocklin

Dies wäre wirklich eine großartige Ergänzung zu NumPy. Was wären die nächsten Schritte, um dies auf typisiert oder NumPy zu bringen? Sogar ein unvollständiger Stub wäre nützlich und ich helfe gerne mit ein bisschen Richtung?

@henryJack Der beste Ausgangspunkt wäre wahrscheinlich das Tooling:

Beginnen Sie dann mit extrem minimalen Anmerkungen und wir können von dort aus fortfahren. Insbesondere würde ich dtype-Annotationen vorerst überspringen, da wir keine gute Möglichkeit haben, sie anzugeben (dh nur ndarray , nicht ndarray[int] ).

Wenn es hilfreich ist, habe ich eine alternative Version von Anmerkungen, die ich zur Verwendung bei Google geschrieben habe und die Open Source sein könnten. Wir haben jedoch unser eigenes einzigartiges Build-System und führen eine Typprüfung mit pytype durch , sodass es wahrscheinlich Macken gibt, die es auf den Upstream

Ich nehme an, die einzige Möglichkeit, Anmerkungen zu testen, um mypy tatsächlich auf Beispielcode-Snippets auszuführen und die Ausgabe zu überprüfen.

Wäre es besser, die Anmerkungen in den Code zu integrieren oder als separate Stubs?

Ich nehme an, wir sollten auch von Dropbox und Pandas lernen, dass wir mit den Blättern der Codebasis im Vergleich zu den Kerndatenstrukturen beginnen sollten.

@shoyer figure out how we can integrate basic type annotations
Wenn Sie nicht einfach https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi in das Basisverzeichnis des numpy- Moduls stellen, tun Sie genau das. In einer experimentellen Version mindestens

Wäre es besser, die Anmerkungen in den Code zu integrieren oder als separate Stubs?

Die Integration in den Code wäre sehr schön, aber ich denke, dass dies für NumPy noch nicht machbar ist. Selbst mit der Kommentarzeichenfolgenversion von Typanmerkungen müssten wir in Python 2 von typing importieren, und das Hinzufügen von Abhängigkeiten zu NumPy ist so gut wie vom Tisch.

Außerdem sind die meisten Kerndatenstrukturen und -funktionen (z. B. ndarray und array ) in Erweiterungsmodulen definiert. Wir müssen dort sowieso Stubs verwenden.

Wenn Sie nicht einfach https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi in das Basisverzeichnis des numpy-Moduls stellen, tun Sie genau das. In einer experimentellen Version mindestens

Ja, ich denke das würde für externen Code ausreichen. Aber wie geht mypy mit Bibliotheken mit unvollständigen Typanmerkungen um?

Wenn möglich, können wir numpy.core.multiarray direkt mit Anmerkungen versehen und nicht nur auf der obersten Ebene. ( multiarray ist das Erweiterungsmodul, in dem NumPys Kerntypen wie ndarray definiert sind.) Ich denke, dies würde es NumPy selbst ermöglichen, die Typprüfung für einige seiner reinen Python-Module zu verwenden.

Ich bin neugierig, was ist die Art von np.empty(shape=(5, 5), dtype='float32') ?

Was ist die Art von np.linalg.svd ?

Es sieht so aus, als wären Typen parametrisiert. Ist dies mit ihrem dtype? Ist es auch möglich, mit ihrer Abmessung oder Form zu parametrisieren? Wie viel Raffinesse unterstützt das Python-Schreibmodul?

Ja, sie werden durch ihren Typ parametrisiert. Ich bin kein Experte auf dem Tipp Modul aber ich denke , Sie nur den ndarray Typen erben haben könnten Generic[dtype, int] parametrisieren auf ndim . Ich glaube, das macht Julia. Ich bin mir nicht sicher, ob Sie die Form leicht parametrisieren können. Ich bin mir auch nicht sicher, welche Vorteile dies bringen würde oder warum dies überhaupt nicht so gemacht wurde.

Kann man numpy dtypes im Parameter dtype verwenden oder kann dies nur eine Eingabe sein?
Modultypen?

Es ist auch seltsam, dass numpy.empty ein Array vom Typ Any zurückgibt. Ich vermute
Es ist eine Herausforderung, den Typ aus dem Schlüsselwortwert dtype = zu übernehmen.

Am 1. September 2017, 18:42 Uhr, schrieb "Jacques Kvam" [email protected] :

Ja, sie werden durch ihren Typ parametrisiert. Ich bin kein Experte für das Tippen
Modul, aber ich denke, Sie könnten nur den ndarray-Typ Generic [dtype,
int], um auf ndim zu parametrisieren. Ich glaube, das macht Julia. Ich bin nicht
sicher, wenn Sie leicht auf Form parametrieren könnten. Ich bin mir auch nicht sicher, was
Vorteile, die bringen würden oder warum es nicht getan wurde, warum überhaupt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
.

Sie können numpy dtypes verwenden, wir müssen sie nur definieren. Das wurde hier mit floating mit np.std gemacht.

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

Ich bin mir nicht sicher, ich denke nicht, dass es möglich ist. Ich glaube nicht, dass Sie den Ausgabetyp basierend auf dem Wert eines Arguments ändern können. Ich denke, das Beste, was wir tun können, ist, die Funktion mit allen Typspezialisierungen zu überladen, die uns wichtig wären.

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

Eine andere Möglichkeit könnte darin bestehen, einige streng typisierte Aliase einzuführen, sodass np.empty[dtype] eine Funktion mit der Signatur (ShapeType) -> ndarray[dtype] .

Es gibt bereits einige Präzedenzfälle dafür mit der ungewöhnlichen np.cast[dtype](x) -Funktion

@jwkvam OK, vielleicht sind dtype Anmerkungen machbar - ich habe nur vorgeschlagen, einfach zu beginnen und von dort fortzufahren .

Ich denke, TypeVar könnte möglicherweise anstelle von Überladungen verwendet werden, vielleicht:

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

Wenn ich das richtig verstehe, würde dies empty(np.float64) -> ndarray[np.float64] bedeuten.

Es wäre auch fantastisch, Informationen zu Form und Dimensionalität von Schecks eingeben zu können, aber ich denke nicht, dass aktuelle Typprüfer der Aufgabe gewachsen sind. Generic[int] ist zum Beispiel ein Fehler - die Argumente für Generic müssen Instanzen von TypeVar :
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

Wir müssten auch Unterschriften mit Dimensionen ausdrücken. Zum Beispiel bildet np.expand_dims ndim -> ndim+1 .

Ich nehme an, ein Ansatz, der funktionieren würde, besteht darin, Klassen für jede nicht negative ganze Zahl zu definieren, z. B. Zero , One , Two , Three , .. . und definieren Sie dann Überlastungen für jede. Das würde sehr schnell anstrengend werden.

In TensorFlow können Sie mit tf.Dimension() und tf.TensorShape() Formen statisch ausdrücken. Aber es ist nicht etwas, was im Typensystem gemacht wird. Vielmehr ist jeder Funktion ein Helfer zugeordnet, der die statische Form von Ausgaben aus der Form von Eingaben und Nicht-Tensor-Argumenten bestimmt. Ich denke, wir würden etwas Ähnliches brauchen, wenn wir dies mit NumPy tun wollten, aber es gibt nichts im Pythons-Tippsystem, was auf diese Art von Flexibilität hindeutet.

@shoyer Ich

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

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

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

Aber ich denke nicht, dass das irgendwohin führt ...

Es scheint, als ob Ihr Beispiel funktioniert! Es schien, als würde es ohne die Typbeschränkungen besser funktionieren. Ich könnte dtypes wie str testen. Ich musste das Standardargument entfernen und konnte nicht herausfinden, wie ich das zum Laufen bringen konnte.

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

und Code

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

Ich bekomme

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

Ich bin ein wenig verwirrt, denn wenn ich die Typen tausche:

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

Ich bekomme keinen Fehler. Auch wenn ich glaube, dass nichts als kovariant markiert ist.

Auch wenn das Typensystem nicht so ausgefeilt ist, wie wir es gerne hätten. Glaubst du, es lohnt sich immer noch? Ein Vorteil, den ich schätzen würde, ist eine bessere Code-Vervollständigung durch jedi.

Ich bin ein wenig verwirrt, denn wenn ich die Typen tausche:

Ich glaube, das Problem hier ist, dass int Instanzen implizit für float Annotationen als gültig angesehen werden. Siehe die Hinweise zum numerischen Turm im Tipp-PEP:
https://www.python.org/dev/peps/pep-0484/#the -numeric-Tower

Ich denke, dies könnte vermieden werden, wenn wir auf NumPy-Skalartypen anstelle von generischen Python-Typen für Anmerkungen bestehen, z. B. np.ndarray[np.integer] statt np.ndarray[int] .

Dies ist tatsächlich ein wenig einfacher als ich dachte, weil TypeVar ein bound Argument hat. Also mein Beispiel überarbeiten:

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

Ich musste das Standardargument entfernen und konnte nicht herausfinden, wie ich das zum Laufen bringen konnte.

Ich bin mir nicht ganz sicher, was du hier vorhast?

Ich habe gerade versucht, den Standardwert von dtype im Stub zu codieren. Das haben sie im mypy-data repo gemacht.

def empty(shape: ShapeType, dtype: DtypeType=float, order: str='C') -> ndarray[Any]: ...

von https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi#L523

Nach Ihrem Beispiel konnte ich mypy nicht dazu bringen, mit einem Standardargument für dtype zu arbeiten. Ich habe dtype: Type[D]=float und dtype: Type[D]=Type[float] ausprobiert.

Ich denke, dtype muss auch ein generischer Typ werden, und dann müssen Sie den Standardwert auf eine numpy generische Unterklasse wie np.float64 anstatt float , z.

# totally untested!
D = TypeVar('D', bound=np.generic)

class dtype(Generic[D]):
    <strong i="9">@property</strong>
    def type(self) -> Type[D]: ...

class ndarray(Generic[D]):
    <strong i="10">@property</strong>
    def dtype(self) -> dtype[D]: ...

DtypeLike = Union[dtype[D], D]  # both are coercible to a dtype
ShapeLike = Tuple[int, ...]

def empty(shape: ShapeLike, dtype: DtypeLike[D] = np.float64) -> ndarray[D]: ...

Das ist nicht richtig. D == type(dtype.type) == type , daher ist Ihre Typparametrisierung nutzlos, da nur D = type .

@ Eric-Wieser Hoppla, ich denke es ist jetzt behoben.

Es gab einige verwandte Diskussionen zum Problem-Tracker von mypy (meistens Python / Mypy # 3540). Dort sehen wir das Hauptproblem darin, dass Numpy-Arrays konzeptionell ihre Dimensionen in ihren Typ einbeziehen, und das aktuelle Typsystem unterstützt dies nicht wirklich. Wenn die mypy- oder typisierten Projekte in irgendeiner Weise dazu beitragen können, dass das Tippen für numpy funktioniert, lassen Sie es uns bitte wissen!

Es gab einige verwandte Diskussionen zum Problem-Tracker von mypy (meistens Python / Mypy # 3540). Dort sehen wir das Hauptproblem darin, dass Numpy-Arrays konzeptionell ihre Dimensionen in ihren Typ einbeziehen, und das aktuelle Typsystem unterstützt dies nicht wirklich. Wenn die mypy- oder typisierten Projekte in irgendeiner Weise dazu beitragen können, dass das Tippen für numpy funktioniert, lassen Sie es uns bitte wissen!

Ich könnte mir vorstellen, hier mehr oder weniger Informationen in parametrisierten Typen zu codieren. Ein Array wie np.empty((2, 3)) kann beispielsweise einen der folgenden Typen haben:

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

@JelleZijlstra Wie ist Ihre Meinung dazu, welche Tools wie mypy wahrscheinlich verarbeiten können? Wie anspruchsvoll können wir werden?

Es scheint ziemlich klar zu sein, dass erhebliche Arbeit im Typensystem erforderlich wäre, um Formen und Dimensionalität zu unterstützen. Ich würde das begrüßen (und habe gerade eine Reihe von Ideen in Python / Mypy # 3540 niedergeschrieben), aber jetzt nennen wir das für NumPy nicht möglich. Angesichts der komplexen Typhierarchie von numpy und der Herausforderungen generischer Typen scheint es schwierig genug zu sein, ndarray[float64] Laufen zu bringen.

Ja, ich denke, dass der erste Schritt darin bestehen würde, grundlegende Tippunterstützung für Numpy (und Pandas und Sklearn) zu erhalten, ohne Formen und andere zusätzliche Einschränkungen für diese Typen zu berücksichtigen.

Das Problem mit anderen zusätzlichen Einschränkungen ist, dass es nicht ausreicht, nur einen d-Typ (Form = 5,6) zu beschreiben, sondern dass es eine Sprache geben muss, um eine Einschränkung für diese Form zu beschreiben. Sie können sich vorstellen, dass Sie eine Funktion definieren möchten, die nur quadratische Zahlenformen als Eingaben akzeptiert, oder eine, bei der eine Dimension 2x die andere sein muss.

So etwas wurde im Vertragsprojekt gemacht .

Ich denke auch, dass PEP 472 hier großartig zu unterstützen wäre, denn dann könnte man wirklich Dinge wie Array[float64, ndim=2] tun.

In der Tat wäre PEP 472 gut zum Tippen geeignet, obwohl es wahrscheinlich eine der einfacheren Lösungen wäre, um dies zu erreichen! (Bitte rufen Sie mich an, wenn Sie daran interessiert sind, die Diskussion darüber neu zu starten, da es meiner Meinung nach auch zwingende Anwendungsfälle für benannte Dimensionen bei der Indizierung gibt.)

Ich bin mir nicht sicher, wie ich dazu beitragen soll, aber ich denke definitiv, dass es aus mehreren Gründen eine großartige Funktion wäre. Aber wir gehen in diese Richtung, dann scheint es, als würde [] einfach eine andere Art sein, ein Objekt aufzurufen. Also macht object(*args, **kwargs) etwas, object[*args, **kwargs] etwas anderes, und dann können wir sogar verallgemeinern und haben auch object{*args, **kwags} und object<*args, **kwargs> . ;-);

@mitar : Wenn wir es anders sehen, sollten wir vielleicht nur mit etwas wie ndarray[float].constrain(ndim=2) kommentieren . Wir haben bereits viele verfügbare Syntaxen und im Gegensatz zu Dekorateuren unterliegen Anmerkungen keinen Einschränkungen

Tatsächlich habe ich die folgende Syntax ausprobiert: ndarray[float](ndim=2) , so dass eine Überladung, die bei Generika __call__ erneut eine Klasse und keine Instanz einer Klasse zurückgibt. Aber es wurde schwierig für Typen, die keine Generika sind.

Ich denke, das Hauptproblem ist die Unterstützung von ndarray[float] , da ndarray[float] nicht wirklich in ndarray existiert. Man müsste ndarray selbst ändern, was Ich bin mir nicht sicher, ob dies ein gutes allgemeines Prinzip ist (Änderung des Upstream-Codes, um eine bessere Eingabe zu unterstützen).

Ein anderer Ansatz könnte darin bestehen, neue Arten von Typvariablen zu haben, ConstrainedTypeVar , bei denen Sie so etwas wie ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) oder so etwas tun könnten, und dann würden Sie A als verwenden var in der Funktionssignatur. Dies wird jedoch sehr ausführlich.

Ich schrieb ein Dokument mit einigen Ideen, wie das Schreiben von Array-Formen beim Senden aussehen könnte, und einem Begriff der Dimensionsidentität.

Die Kernideen umfassen:

  1. Hinzufügen eines DimensionVar -Primitivs, das symbolische Identitäten für Array-Dimensionen zulässt
  2. Erkennen von ... ( Ellipsis ) als anzeigendes Array-Broadcasting.

Geben Sie beispielsweise np.matmul / @ :

from typing import DimensionVar, NDArray, overload

I = DimensionVar('I')
J = DimensionVar('J')
K = DimensionVar('K')

<strong i="17">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[..., J, K]) -> NDArray[..., I, K]: ...

<strong i="18">@overload</strong>
def matmul(a: NDArray[J], b: NDArray[..., J, K]) -> NDArray[..., K]: ...

<strong i="19">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[J]) -> NDArray[..., I]: ...

Dies würde ausreichen, um generalisierte Ufuncs eingeben zu

Eine mögliche Lösung zur Unterstützung von d-Typen und Formen, wenn wir bereits NDArray und ndarray unterscheiden:

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

Nur ein Gedanke, wäre es sinnvoll, auch eine solche Verknüpfung zu haben?

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

- was eine Reihe von Signaturen vereinfachen könnte, insbesondere im nachgeschalteten Code.

@aldanor Ich denke du meinst NDArray.shape[:, :] ( ... bedeutet "null oder mehr Dimensionen", was in diesem Zusammenhang nicht ganz richtig ist). Aber ja, das sieht vernünftig aus.


Schnelles Update zum Tippen für dtypes: Ich habe ein Spielzeugmodul mit dem oben beschriebenen Ansatz geschrieben, der np.generic Unterklassen mit Generic für parametrisierte ndarray / dtype Typen verwendet .

Dies scheint meistens mit mypy zu funktionieren, wie ich es erwarten würde, einschließlich Typinferenz mit dem Äquivalent von np.empty(..., dtype=np.float32) . Es kann einen meiner absichtlichen Typfehler mit einem Union -Typ nicht abfangen (ich werde später einen Fehlerbericht einreichen).

Ich denke, das wäre wahrscheinlich gut genug für dtypes. Ohne Eingabeunterstützung für Literalwerte könnten wir keine Typinferenz mit dem als Zeichenfolgen angegebenen dtype ( dtype='float32' ) durchführen. Vielleicht problematischer ist, dass es auch keine Typinferenz von Python-Typen wie dtype=float . Diese Typen können jedoch mehrdeutig sein (z. B. dtype=int np.int64 unter Linux und np.int32 unter Windows), daher ist es wahrscheinlich sowieso besser, explizite generische Typen zu verwenden. Es ist in Ordnung, wenn die Typinferenz nicht in jedem möglichen Fall funktioniert, solange die Spezifikationen dtype=float als ein Typ von Any anstatt einen Fehler auszulösen.

Diese Typen können jedoch mehrdeutig sein (z. B. dtype = int ist unter Linux np.int64 und unter Windows np.int32 zugeordnet).

Das ist nicht mehrdeutig - in allen Fällen entspricht dies np.int_ , dem Typ C long .

Ich habe die Mailingliste geschrieben, um einen Konsens über das Schreiben von Typ-Stubs für NumPy in einem separaten Paket zu erzielen:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

Erstaunlich, danke @shoyer !

Gemäß dem Konsens auf der Mailingliste möchte ich https://github.com/numpy/numpy_stubs für geschäftlich offen erklären!

Wir beginnen mit grundlegenden Anmerkungen (keine dtype-Unterstützung). Wenn jemand eine grundlegende PR zusammenstellen möchte, um das PEP 561-Gerüst für das Repo hinzuzufügen, wäre er dankbar!

JA, JA, 1000X JA!

Heads-up für alle, die dieses Problem verfolgen: Ich habe zwei Probleme mit dem Python / Typing-Tracker geöffnet:

  • ndarray-Eingabe im Allgemeinen (https://github.com/python/typing/issues/513)
  • Syntax für die Eingabe von ndarray (https://github.com/python/typing/issues/516)

Was ist die erwartete Veröffentlichungszeit für die Eingabefunktion?
Gibt es einen Grund, die Kompatibilität mit 2.7 aufrechtzuerhalten?
In einem frühen Kommentar wurde auf Schwierigkeiten bei der Integration in Python 2 hingewiesen. Seitdem scheint Numpy seine Haltung geändert zu haben.

Ich weiß, dass sich Dinge bewegen, aber wäre es sinnvoll, auf etwas wie Python 3.4-3.6 zu zielen?

Was ist die erwartete Veröffentlichungszeit für die Eingabefunktion?

Bei PyCon gab es mehrere Diskussionen darüber (Integer-Generika, auch einfache abhängige Typen genannt). Ich werde ein Proto-PEP schreiben, das auf diesen Diskussionen und dem von @shoyer geschriebenen Originaldokument typing für Python 2 ist sehr wahrscheinlich).

@hmaarrfk Was das Schreiben von betrifft , haben wir damit begonnen, dies in einem separaten Repository zu tun: https://github.com/numpy/numpy-stubs. Sie sollten in der Lage sein, diese Stubs im aktuellen Status (mit der neuesten Version von mypy) zu installieren und zu verwenden, aber sie sind noch lange nicht vollständig. Hilfe wäre dankbar!

Klar, ich bin froh zu helfen, wo ich kann, und ich habe das Repository gesehen. Ich weiß nur, dass diese Dinge Zeit brauchen.
Ich sah das Repo und bemerkte ein Commit, das die 2.7-Kompatibilität erwähnte, weshalb ich fragte.

Die Beta-Release-Zeit für Python 3.8 ist Mitte 2019 . Numpy erwähnte, dass sie neue Funktionen Ende 2018 einstellen würden.

Das Tippen scheint für Numpy eine "nice-to-have" -Funktion zu sein, im Gegensatz zu einem "must-have". Daher scheint es etwas schwierig zu sein, auf zwei Sprachen abzuzielen, insbesondere dann, wenn die Funktion weit über die Support-Frist von numpy hinaus angezeigt wird.

Ich werde gerne lesen, was

@hmaarrfk Sie

Im Moment scheint es nicht viele Kompromisse zu erfordern, um Python 2 in unseren Typanmerkungen zu unterstützen, daher lasse ich es gerne dabei, insbesondere angesichts der Tatsache, dass es von einem Mitwirkenden stammt, der offensichtlich daran interessiert war.

Ich wollte dies noch einmal durchgehen, um zu sehen, ob die Diskussionen fortgeschritten sind, insbesondere in Bezug auf typinformierende Forminformationen, die in vielen meiner Anwendungen besonders nützlich wären. Gibt es einen Status-Tracker oder ist dieser nicht hoch genug, um Ressourcen dafür bereitzustellen?

In transonic , einem Projekt zur Verallgemeinerung von Numpy-Beschleunigern, haben wir eine Typ-Hinweis-Syntax als Alternative für Pythran-Annotationen, die Kommentare verwenden . Es funktioniert momentan nicht gut mit mypy, aber ich frage mich, ob es nützlich ist. Siehe ein Beispiel: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

Falls es für dieses Problem nützlich ist, werde ich erwähnen, dass ich ein Tool zum Konvertieren von Dokumentzeichenfolgen in Typkommentare erstellt habe: https://pypi.org/project/doc484/

Ich verwende dies mit Pre-Commit in mehreren Projekten, um Docstrings mit Typkommentaren synchron zu halten.

Sie müssen die Typen in Ihren Dokumentzeichenfolgen noch konvertieren, um PEP484-kompatibel zu sein.

Hallo, alle miteinander,

Ich wollte meinen Teil dazu beitragen, also gabelte ich das Repo und begann, Typhinweise hinzuzufügen. Meine Idee war es, von unten nach oben zu arbeiten. Beginnen Sie also mit den "einfachen" Funktionen und arbeiten Sie von dort aus nach oben. (Beginnend mit den tief hängenden Früchten)

Zum Beispiel habe ich in _string_helpers.py einigen Variablen und Funktionen Typhinweise hinzugefügt.

LOWER_TABLE: str = "".join(_all_chars[:65] + _ascii_lower + _all_chars[65 + 26:])
UPPER_TABLE: str = "".join(_all_chars[:97] + _ascii_upper + _all_chars[97 + 26:])

def english_lower(s: str) -> str:
    """ Apply English case rules to convert ASCII strings to all lower case.
   ...
    """
    lowered = s.translate(LOWER_TABLE)
    return lowered

Was denkst du darüber?

Ich würde empfehlen, ein wenig zu tun und eine PR zu öffnen, um Kommentare zu erhalten. numpy zielt auf ältere Pythons ab (3.5 eingeführte Anmerkungen, IIRC), und dies würde diese Builds beschädigen. Sehen Sie sich also möglicherweise das Schreiben von .pyi-Dateien an oder überprüfen Sie die mypy-Dokumente, um festzustellen, ob es weitere Anleitungen zu Best Practices gibt.

Bisher haben wir Anmerkungen in den einzelnen Numpy-Stubs gemacht
Repository, aber es war ein langsamer Prozess.

Am Do, 14. November 2019 um 9:57 Uhr schrieb Ben Samuel [email protected] :

Ich würde empfehlen, ein wenig zu tun und eine PR zu öffnen, um Kommentare zu erhalten. numpy
zielt auf ältere Pythons ab (3.5 eingeführte Anmerkungen, IIRC) und dies
würde diese Builds brechen, also schauen Sie vielleicht in das Schreiben von .pyi-Dateien oder überprüfen
In den mypy-Dokumenten finden Sie Informationen zu bewährten Methoden.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/7370?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

@ bsamuel-ui numpy erfordert derzeit Python 3.5+, und der NEP-29 [1] gibt an, dass es in Ordnung sein sollte, es auf 3.6+ zu erhöhen
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

Anmerkungen (für Funktionsargumente und Rückgabetypen) werden tatsächlich in allen Python 3-Versionen unterstützt. 3.6 führte nur variable Annotationen ein. In der frühen Python 3-Version (<3.5) müssen Sie einen Backport des Moduls typing .

Ich habe mit meiner ersten .pyi-Datei eine Pull-Anfrage hinzugefügt. Es braucht etwas Arbeit, aber es wäre schön, wenn ihr es euch ansehen könnt, damit ich ein erstes Feedback bekomme

Wie in gh-14905 erwähnt, haben wir die Anfänge einer Stub-Bibliothek in https://github.com/numpy/numpy-stubs. Es wäre großartig, dies mit geeigneten Tests in Gang zu bringen, und dann könnten wir entscheiden, wie wir es am besten verpacken oder in numpy / numpy richtig zusammenführen.

Mein schlechtes @mattip. Ich werde die Pull-Anfrage von numpy entfernen und numpy-stubs eine neue hinzufügen

Es ist noch geöffnet, aber ich glaube, dass Numpy dies bereits in der Master-Version unterstützt

Hallo,
Ich versuche, einen Typ-Alias ​​für den Vektor 3d zu definieren, also ein numpy-Array der Form (3,) vom Typ int32.

(Ich weiß, dass ich mit np.ndarray einen Hinweis eingeben kann, aber wie werde ich genauer? Ich habe hier alles gelesen und es nicht verstanden. Ich suche auch nach einem Tutorial, wie man numpy-Typen zum Tippen in Python verwendet, aber nicht irgendetwas finden. )

Als ob es möglich wäre zu schreiben:

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

Ich habe versucht zu tun:

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

Ist es der richtige Weg?

Kann mir hier jemand ein Tutorial oder ein Beispiel zeigen?

Außerdem habe ich dieses Repo gefunden, das "Tipphinweise für Numpy" lautet: https://github.com/ramonhagenaars/nptyping

Wird Numpy dies integrieren?
@ramonhagenaars

@ Mattip

Wie in gh-14905 erwähnt, haben wir die Anfänge einer Stub-Bibliothek in https://github.com/numpy/numpy-stubs.

Es sieht so aus, als wäre dies in das Haupt-Repo integriert worden. Wurde dies veröffentlicht oder steht es auf der Roadmap? Versuchen Sie zu entscheiden, ob wir etwas von Drittanbietern wie https://github.com/ramonhagenaars/nptyping untersuchen oder (im Idealfall) auf offiziell unterstützte Typhinweise warten / diese verwenden sollen.

Vielen Dank.

Wir haben viele Numyp-Stubs in den Entwicklungszweig integriert. Sie können den Fortschritt verfolgen, indem Sie nach der statischen Typisierungsbezeichnung suchen. Hoffentlich wird dies Teil der nächsten Version sein. Sie können ausprobieren, was gerade zusammengeführt wird, indem Sie eine HEAD-Version von numpy verwenden. Wir sind immer auf der Suche nach Mitwirkenden: Eine konstruktive Überprüfung, Dokumentation und Kommentare zu den Problemen sowie Pull-Anfragen sind einige Möglichkeiten, um zu helfen.

(Ich weiß, dass ich mit np.ndarray einen Hinweis eingeben kann, aber wie werde ich genauer? Ich habe hier alles gelesen und es nicht verstanden. Ich suche auch nach einem Tutorial, wie man numpy-Typen zum Tippen in Python verwendet, aber nicht irgendetwas finden. )

In diesem Bereich besteht großes Interesse, aber eine spezifischere Typisierung (d-Typen und Dimensionen) für NumPy-Arrays wird noch nicht unterstützt.

@ GilShoshan94 FWIW Ich habe https://github.com/ramonhagenaars/nptyping/issues/27 eingereicht

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen