Numpy: ndarray、dtype、およびufuncの型ヒント/注釈（PEP 484）

私は誰もそれについて考えていないと思います。 たぶんあなたはしたいですか？ :-)

また、これについてフォローアップしたい場合は、オープンエンドの設計ディスカッションに適しているため、ghの問題を閉じて、ディスカッションをメーリングリストに移動することをお勧めします。

SOでこの回答を得た後、問題を解決することにしました。

明確にするために、私たちは実際には、クールな新しいPython機能や何か（むしろその逆）をサポートすることに異議はありません。 私たちが多くのリソースを持たないボランティアが運営するプロジェクトであるというだけなので、興味のある人がそれを実行するためにステップアップした場合にのみ、何かが起こります。

メーリングリストは通常​​、何かに取り組み始めようとしている場合、または他の関心のある人々を助けてくれる人を募集したい場合に最適な場所です。

ありがとう、@ njsmith。 構造化されていないメーリングリストとは対照的に、より整然とした問題追跡のためにここから始めることにしました（他の機能の中でも特に「機能リクエスト」タグを探していました...）

SOで私に答えた人が実行可能な解決策で私に戻ってきたので、私は問題を残すことにしました。
たぶん、Numpyのドキュメントを更新して、彼の答えを含める必要があります（そうする場合は、必ず彼にクレジットを与えてください）。

再度、感謝します！

こんにちはみんな！ この問題について何か進展があったかどうか、私は親切に思っていました。 ありがとう。

こちらのメーリングリストでそれについての議論があり

さらに議論したい方のために、この号を再開します。

これはNumPyにとって確かに望ましいことだと思いますが、NumPyが現在np.arrayコンストラクターで任意のオブジェクトを受け入れる方法など、入力して並べ替えるためのNumPy APIには確かにいくつかのトリッキーな側面があります（ただし、これをクリーンアップします。https：//github.com/numpy/numpy/issues/5353を参照してください）。

いくつかの良い仕事がここで行われています： https ：

作業を上流のnumpyまたはtypeshedのどちらにプッシュするかについての議論があります： //github.com/machinalis/mypy-data/issues/16

CC @mrocklin

これは本当にNumPyへの素晴らしい追加になるでしょう。 これをtypeshedまたはNumPyにプッシュするための次のステップは何でしょうか？ 不完全なスタブでも役に立ちます。少しの指示を喜んでお手伝いしますか？

@henryJack開始するのに最適な場所は、おそらくツールです。mypyと連携し、段階的な追加をサポートする方法で、基本的な型アノテーションをNumPyリポジトリに統合する（理想的にはテストする）方法を見つけます。

次に、非常に最小限の注釈から始めて、そこから進むことができます。 特に、dtypeアノテーションを指定する適切な方法がないため、今のところスキップします（つまり、 ndarrayではなくndarray[int] ndarrayのみを実行します）。

それが役に立ったら、Googleで使用するために作成した、オープンソースの注釈の代替バージョンがあります。 ただし、独自のビルドシステムがあり、 pytypeを使用して型チェックを行うため、アップストリームに移植する際に癖が生じる可能性があります。

サンプルコードスニペットでmypyを実際に実行して出力を確認するために、アノテーションをテストする唯一の方法だと思いますか？

アノテーションをコードと統合するか、個別のスタブとして統合する方がよいでしょうか？

ドロップボックスとパンダから、コードベースとコアデータ構造の葉から始める必要があることも学ぶ必要があると思いますか？

@shoyer figure out how we can integrate basic type annotations
https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyiをnumpyモジュールのベースディレクトリに置くだけではありません。ある種の実験バージョンでは、まさにそれを行います。少なくとも

アノテーションをコードと統合するか、個別のスタブとして統合する方がよいでしょうか？

コードと統合するのは素晴らしいことですが、NumPyではまだ実現可能ではないと思います。 型アノテーションのコメント文字列バージョンを使用しても、Python 2ではtypingからインポートする必要があり、NumPyへの依存関係の追加はほとんどテーブルから外れています。

また、コアデータ構造と関数のほとんど（ ndarrayやarray ）は拡張モジュールで定義されているため、とにかくそこでスタブを使用する必要があります。

https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyiをnumpyモジュールのベースディレクトリに置くだけではありません。ある種の実験バージョンでは、まさにそれを行います。少なくとも

はい、外部コードにはそれで十分だと思います。 しかし、mypyは不完全な型アノテーションを持つライブラリをどのように処理しますか？

可能であれば、トップレベルだけでなく、 numpy.core.multiarray直接注釈を付けることもできます。 （ multiarrayは、 ndarrayようなNumPyのコア型が定義されている拡張モジュールです。）これにより、NumPy自体が純粋なPythonモジュールの一部の型チェックを利用できるようになると思います。

私は興味があります、 np.empty(shape=(5, 5), dtype='float32')のタイプは何ですか？

np.linalg.svdの種類は何ですか？

@kjyvはそれらを定義することに

np.empty ： https ：
np.linalg.svd ： https ：

タイプがパラメータ化されているように見えますが、これはdtypeと同じですか？ それらの寸法または形状でパラメータ化することも可能ですか？ Pythonのタイピングモジュールはどのくらい洗練されていますか？

ええ、それらはそれらのdtypeによってパラメータ化されています。 私はタイピングモジュールには専門家だが、私はあなただけ継承ndarrayタイプを持っていると思うGeneric[dtype, int]でパラメータ化するためにndim 。 それがジュリアがしていることだと思います。 形状を簡単にパラメータ化できるかどうかはわかりません。 また、どのようなメリットがもたらされるのか、そもそもなぜそのように行われなかったのかについてもわかりません。

dtypeパラメータでnumpydtypesを使用できますか、それとも入力のみが可能ですか？
モジュールタイプ？

また、numpy.emptyがAny型の配列を返すのも奇妙です。 疑わしい
dtype =キーワード値から型を取得するのは難しいですか？

2017年9月1日午後6時42分、「JacquesKvam」 [email protected]は次のように書いています。

ええ、それらはそれらのdtypeによってパラメータ化されています。 私はタイピングの専門家ではありません
モジュールですが、ndarray型にGeneric [dtype、
int] ndimでパラメータ化します。 それがジュリアがしていることだと思います。 私は違います
形状を簡単にパラメータ化できるかどうかを確認してください。 また、私は何を確信していません
そもそも、それがもたらすメリットや、なぜそれが行われなかったのか。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
。

numpy dtypeを使用できますが、定義する必要があります。 これは、np.stdを使用したfloatingでここで行われました。

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

よくわかりませんが、それは不可能だと思います。 引数の値に基づいて出力タイプを変更することはできないと思います。 私たちができる最善のことは、私たちが気にするすべての型の特殊化で関数をオーバーロードすることだと思います。

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

もう1つのオプションは、厳密に型指定されたエイリアスを導入することです。したがって、 np.empty[dtype]は、シグネチャ(ShapeType) -> ndarray[dtype]持つ関数です。

珍しいnp.cast[dtype](x)関数でこれにはすでにいくつかの前例があります

@jwkvam OK、それで多分dtypeアノテーションが実行可能です-私は単純に始めてそこから行くことを提案していました。

私が考えるTypeVar多分、おそらく代わりに過負荷を使用することができます：

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

私がこれを正しく理解していれば、これはempty(np.float64) -> ndarray[np.float64]を意味します。

チェックの形状と次元の情報を入力できるのも素晴らしいことですが、現在のタイプチェッカーはその任務を果たせないと思います。 たとえば、 Generic[int]はエラーです。 Genericへの引数はTypeVarインスタンスである必要があります。
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

また、ディメンションを含む署名を表現する必要があります。 たとえば、 np.expand_dimsはndim -> ndim+1マップします。

うまくいく1つのアプローチは、負でない整数ごとにクラスを定義することだと思います。たとえば、 Zero 、 One 、 Two 、 Three 、.. 。次に、それぞれのオーバーロードを定義します。 それはすぐに疲れます。

TensorFlowでは、 tf.Dimension()とtf.TensorShape() 、形状を静的に表現できます。 しかし、それは型システムで行われることではありません。 むしろ、各関数には、入力の形状とテンソル以外の引数から出力の静的な形状を決定するヘルパーが関連付けられています。 NumPyでこれを実行したい場合は、同様の何かが必要になると思いますが、Pythonのタイピングシステムには、この種の柔軟性を示唆するものはありません。

@shoyerなるほど、残念です。 私は以下をハックすることができました

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

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

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

しかし、それがどこをリードしているとは思いません...

あなたの例はうまくいくようです！ タイプの制約がなくてもうまく機能するように見えました。 strようなdtypeをテストできます。 デフォルトの引数を削除する必要があり、それを機能させる方法がわかりませんでした。

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

とコード

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

私は得る

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

タイプを交換すると、少し混乱します。

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

エラーは発生しません。 共変としてマークされているものはないと思いますが。

型システムは私たちが望むほど洗練されていませんが。 それでも価値があると思いますか？ 私が感謝する1つの利点は、jediを介したより良いコード補完です。

タイプを交換すると、少し混乱します。

ここでの問題は、 intインスタンスがfloatアノテーションに対して暗黙的に有効であると見なされることだと思います。 入力PEPの数値タワーに関する注記を参照してください。
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

アノテーションに汎用PythonタイプではなくNumPyスカラータイプを要求すれば、これを回避できると思います。たとえば、 np.ndarray[np.integer]ではなくnp.ndarray[int]です。

TypeVarにはbound引数があるので、これは実際には私が思っていたよりも少し簡単です。 だから私の例を修正する：

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

デフォルトの引数を削除する必要があり、それを機能させる方法がわかりませんでした。

ここで何を得ているのかよくわかりませんか？

dtypeのデフォルト値をスタブにエンコードしようとしました。 彼らはmypy-dataリポジトリでそれを行いました。

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

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

あなたの例に従って、mypyをdtypeのデフォルト引数で動作させることができませんでした。 dtype: Type[D]=floatとdtype: Type[D]=Type[float]を試しました。

dtypeもジェネリック型になる必要があると思います。次に、デフォルト値をfloatではなくnp.float64ようなnumpyジェネリックサブクラスに設定する必要があります。

# 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]: ...

そうではありません。 D == type(dtype.type) == typeであるため、使用されるパラメーターはD = typeのみであるため、型のパラメーター化は役に立ちません。

@ eric-wieserおっと、今は修正されたと思います。

mypyの課題追跡システム（主にpython / mypy＃3540）についていくつかの関連する議論がありました。 そこでは、numpy配列の型に概念的に次元が含まれていることが主な問題であると認識していますが、現在の型システムは実際にはそれをサポートしていません。 mypyまたはtypeshedプロジェクトが、numpyでタイピングを機能させるのに何らかの形で役立つ場合は、お知らせください。

mypyの課題追跡システム（主にpython / mypy＃3540）についていくつかの関連する議論がありました。 そこでは、numpy配列の型に概念的に次元が含まれていることが主な問題であると認識していますが、現在の型システムは実際にはそれをサポートしていません。 mypyまたはtypeshedプロジェクトが、numpyでタイピングを機能させるのに何らかの形で役立つ場合は、お知らせください。

ここでは、パラメータ化されたタイプで多かれ少なかれ情報をエンコードすることを想像できます。 たとえば、 np.empty((2, 3))ような配列は、次のいずれかのタイプになります。

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

@JelleZijlstra mypyのようなツールで処理できる可能性が高いものについて、ここであなたの意見は何ですか？ どれだけ洗練されたものになれますか？

形状と次元をサポートするには、型システムでかなりの作業が必要になることは明らかです。 私はそれを歓迎します（そしてpython / mypy＃3540にたくさんのアイデアを書き留めました）が、今のところそれをNumPyの範囲外と呼びましょう。 numpyの複雑な型階層とジェネリック型の課題を考えると、 ndarray[float64]機能させるだけでも十分に難しいようです。

はい、最初のステップは、numpy（およびPandasとsklearn）の基本的なタイピングサポートを取得することであり、それらのタイプに対する形状やその他の追加の制約を考慮しないことだと思います。

他の追加の制約の問題は、dtype（shape = 5,6）を記述するだけでは不十分ですが、その形状の制約を記述するための言語が必要であるということです。 正方形のnumpy形状のみを入力として受け入れる関数、または1つの次元が他の次元の2倍でなければならない関数を定義したいと考えることができます。

そのようなことは契約プロジェクトで行われました。

また、 PEP 472は、ここでサポートするのに最適だと思います。そうすれば、 Array[float64, ndim=2]ようなことが実際にできるからです。

確かに、PEP 472はタイピングに適していますが、これを実現するためのより簡単な修正の1つになるでしょう。 （インデックス作成における名前付きディメンションの説得力のあるユースケースもあると思うので、それに関する議論を再開することに興味がある場合は、私にpingしてください。）

自分がどのように貢献しているかはわかりませんが、さまざまな理由から素晴らしい機能になると思います。 しかし、その方向に進んでいると、 []がオブジェクトを呼び出す別の方法になっているように見えます。 つまり、 object(*args, **kwargs)は何かを実行し、 object[*args, **kwargs]他の何かを実行します。その後、一般化してobject{*args, **kwags}とobject<*args, **kwargs>を使用することもできます。 ;-)

@mitar ：ndarray[float].constrain(ndim=2)ような注釈を付ける必要があります。 すでに利用可能な構文がたくさんあり、デコレータとは異なり、アノテーションには制限がありません

私は実際に次の構文を試しました： ndarray[float](ndim=2)なので、ジェネリックで__call__オーバーロードすると、クラスのインスタンスではなく、クラスが再び返されます。 しかし、ジェネリックではない型では注意が必要になりました。

ndarray[float]はndarrayに実際に存在するものではないため、主な問題はndarray[float]サポートにあると思います。これは、 ndarray自体を変更する必要があります。一般的な原則が適切かどうかはわかりません（より適切なタイピングをサポートするためにアップストリームコードを変更する）。

もう1つのアプローチは、新しいタイプの型変数ConstrainedTypeVarを使用することです。ここで、 ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2)などを実行し、 Aとして使用します。関数シグネチャのvar。 しかし、これは非常に冗長になります。

ブロードキャストで配列の形状を入力するとどのように見えるか、および次元の同一性の概念について、いくつかのアイデアを記載したドキュメントを作成し

コアアイデアは次のとおりです。

1. 配列次元のシンボリックIDを可能にするDimensionVarプリミティブを追加する
2. ... （ Ellipsis ）を指示配列ブロードキャストとして認識します。

たとえば、 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]: ...

これらは、一般化されたufuncを入力できるようにするのに十分

NDArrayとndarray区別することをすでに選択している場合、dtypeとshapeの両方をサポートするための可能な解決策：

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

考えてみれば、このようなショートカットもあるのは理にかなっていますか？

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

—これにより、特にダウンストリームコードで、多くの署名が簡素化される可能性があります。

@aldanorあなたはNDArray.shape[:, :]を意味すると思います（ ...は「ゼロ以上の次元」を意味しますが、この文脈では正しくありません）。 しかし、はい、それは合理的に見えます。

dtypesの入力に関するクイックアップデート：パラメータ化されたndarray / dtypeタイプにGenericを含むndarray np.genericサブクラスを使用する上記のアプローチを使用しておもちゃモジュールを作成しました。

これは、 np.empty(..., dtype=np.float32)相当する型推論を含め、私が期待するようにmypyでほとんど機能するようです。 Unionタイプに関連する意図的なタイプエラーの1つをキャッチできません（後でバグレポートを提出します）。

これはおそらくdtypeには十分だと思います。 リテラル値のサポートを入力しないと、文字列（ dtype='float32' ）として指定されたdtypeで型推論を行うことができませんdtype=floatようなPython型からの型推論も処理しないことです。 ただし、これらの型はあいまいになる可能性があるため（たとえば、 dtype=intはLinuxではnp.int64に、Windowsではnp.int32にマップされます）、とにかく明示的なジェネリック型を使用することをお勧めします。 仕様dtype=floatがエラーを発生させるのではなくAny dtypeとして推論される限り、型推論がすべての可能な場合に機能しない場合でも問題ありません。

ただし、これらの型はあいまいになる可能性があります（たとえば、dtype = intはLinuxではnp.int64に、Windowsではnp.int32にマップされます）。

これはあいまいではありません。すべての場合で、C longタイプであるnp.int_にマップされます。

NumPyのタイプスタブを別のパッケージで作成することについてコンセンサスを得るために、メーリングリストを作成しました。
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

素晴らしい、ありがとう@shoyer ！

メーリングリストのコンセンサスに従って、 https：//github.com/numpy/numpy_stubsが営業を開始していることを宣言したいと思い

基本的な注釈から始めます（dtypeはサポートされていません）。 誰かが基本的なPRをまとめて、レポのPEP 561足場を追加したい場合は、よろしくお願いします。

はい、はい、1000Xはい！

この問題をフォローしている人に注意してください：私はpython / typingトラッカーで2つの問題を開きました：

• 一般的なndarrayタイピング（https://github.com/python/typing/issues/513）
• ndarrayタイピングの構文（https://github.com/python/typing/issues/516）

タイピング機能の予想リリース時間はどれくらいですか？
2.7の互換性を維持しようとする理由はありますか？
初期のコメントでは、Python 2との統合の難しさについて言及されていました。それ以来、numpyはそのスタンスを変えたようです。

物事は動くターゲットですが、Python 3.4-3.6のようなものをターゲットにすることは理にかなっていますか？

タイピング機能の予想リリース時間はどれくらいですか？

PyConでこれ（整数ジェネリック、別名単純依存型）についていくつかの議論がありました。これらの議論と、 @ shoyerによって作成された元のドキュメントに基づいてプロトPEPをtypingでの新しいタイプの後続のバックポートも可能性が高いです）

@hmaarrfk NumPy自体の型アノテーションの記述については、別のリポジトリhttps://github.com/numpy/numpy-stubsで開始しました

確かに、私はできる限り助けてくれてうれしいです、そして私はリポジトリを見ました。 私はこれらのことが時間がかかることを知っています。
私はリポジトリを見て、2.7の互換性について言及されているコミットに気づきました。それが私が尋ねた理由です。

Python3.8ベータリリース時間は2019年半ばです。 Numpyは、 2018年末に新機能を停止すると述べました。

入力は、「必須」ではなく、numpyの「必須」機能のようです。 そのため、特に機能がnumpy自身のサポート期限をはるかに超えて表示され始める場合は、2つの言語をターゲットにするのは少し難しいようです。

@ilevkivskyiがPEPで言っていることを読むことに興味があります。

@hmaarrfk Python2.7のサポートについて良い点を挙げています。 正直、まだ十分に考えていません。 タイピングの主なユースケースがPython2 / 3互換コードの記述であることを考えると、最終的には削除されると思いますが、mypy自体がPython2.7サポートを削除する前ではないでしょう。

今のところ、型アノテーションでPython 2をサポートするために多くの妥協は必要ないようです。特に、明らかに興味を持った寄稿者からのものであることを考えると、そのままにしておくことができます。

これをもう一度調べて、特にタイプヒントの形状情報に関して議論が進んでいるかどうかを確認したいと思いました。これは、多くのアプリケーションで特に役立ちます。 ステータストラッカーはありますか、それともリソースを専用にするのに十分な優先度ではありませんか？

numpyアクセラレーターを一般化するプロジェクトであるtransonicは、コメントを使用するます。 今のところmypyではうまく機能しませんが、役に立つのではないかと思います。 例を参照してください： https ：

この問題に役立つ場合は、docstringをタイプコメントに変換するためのツールを作成したことをお伝えします： https ：

これをいくつかのプロジェクトのpre-commitで使用して、docstringをタイプコメントと同期させます。

それでも、DocstringのタイプをPEP484に準拠するように変換する必要があります。

みなさん、こんにちは、

私は自分の役割を果たしたかったので、リポジトリをフォークしてタイプヒントを追加し始めました。 私の考えはボトムアップで作業することだったので、「単純な」機能から始めて、そこから上に向かって作業します。 （ぶら下がっている果物から始めます）

たとえば、 _string_helpers.pyでは、いくつかの変数と関数に型ヒントを追加しました。

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

これについてあなたはどう思いますか？

コメントを得るために少しやってPRを開くことをお勧めします。 numpyは古いpython（3.5で導入されたアノテーション、IIRC）をターゲットにしており、これによりビルドが破損する可能性があるため、.pyiファイルの作成を検討するか、mypyドキュメントをチェックして、ベストプラクティスに関するガイダンスがもう少しあるかどうかを確認してください。

これまで、個別のnumpy-stubで注釈を付けてきました
リポジトリですが、プロセスが遅くなっています。

9:57ベンサミュエルの木、2019年11月14日に[email protected]書きました：

コメントを得るために少しやってPRを開くことをお勧めします。 numpy
古いニシキヘビ（3.5導入されたアノテーション、IIRC）とこれをターゲットにしています
それらのビルドを壊してしまうので、.pyiファイルの書き込みを検討するかチェックしてください
mypyのドキュメントで、ベストプラクティスに関するガイダンスがもう少しあるかどうかを確認します。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
。

@ bsamuel-uinumpyには現在Python3.5 +が必要であり、NEP-29 [1]は、3.6 +にバンプしても問題ないと述べています。
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

アノテーション（関数の引数と戻り値の型）は、実際にはすべてのPython3バージョンでサポートされています。 3.6では変数アノテーションのみが導入されました。 初期のPython3バージョン（<3.5）では、 typingモジュールのバックポートを使用する必要があります。

最初の.pyiファイルでプルリクエストを追加しました。 いくつかの作業が必要ですが、最初のフィードバックを得ることができるように、皆さんがそれを見ていただければ幸いです。

gh-14905で述べたように、 https：//github.com/numpy/numpy-stubsにスタブライブラリの始まりがあり

私の悪い@mattip。 numpyからプルリクエストを削除し、numpy-stubsに新しいリクエストを追加します

まだ開いていますが、numpyはマスターバージョンですでにそれをサポートしていると思います

こんにちは、
ベクトル3dのタイプエイリアスを定義しようとしているので、dtype int32の形状（3、）のnumpy配列。

（np.ndarrayでヒントを入力できることはわかっていますが、より具体的にするにはどうすればよいですか？ここをすべて読んでもわかりませんでした。Pythonで入力するためにnumpy型を使用する方法に関するチュートリアルも検索しましたが、しませんでした。何かを見つけます。）

それが書くことが可能であるように：

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

私がやろうとした：

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

それは正しい方法ですか？

ここの誰かが私にチュートリアルや例を教えてもらえますか？

また、「Numpyのタイプヒント」であるこのリポジトリを見つけました： https ：

Numpyはこれを統合しますか？
@ramonhagenaars

@mattip

gh-14905で述べたように、 https：//github.com/numpy/numpy-stubsにスタブライブラリの始まりがあり

これはメインリポジトリに統合されたようです。 これはリリースされましたか、それともロードマップにありますか？ https://github.com/ramonhagenaars/nptypingのようなサードパーティを探索するか、（理想的には）公式にサポートされているタイプヒントを待つ/使用するかを決定しようとしています。

ありがとう。

numyp-stubの多くを開発ブランチに統合しました。 静的型付けラベルを探すことで、進行状況を追跡できます。 うまくいけば、これは次のリリースの一部になるでしょう。 ヘッドバージョンのnumpyを使用して、現在マージされているものを試すことができます。 私たちは常に貢献者を探しています。問題に関する建設的なレビュー、ドキュメント、コメント、プルリクエストは役立ついくつかの方法です。

（np.ndarrayでヒントを入力できることはわかっていますが、より具体的にするにはどうすればよいですか？ここをすべて読んでもわかりませんでした。Pythonで入力するためにnumpy型を使用する方法に関するチュートリアルも検索しましたが、しませんでした。何かを見つけます。）

この分野には多くの関心が寄せられていますが、NumPy配列のより具体的なタイピング（dtypesとdimensions）はまだサポートされていません。

@ GilShoshan94FWIW私はhttps://github.com/ramonhagenaars/nptyping/issues/27を提出しました

また、FWIW、オーバーロードの__doc__文字列の「注釈」タイプの署名にpybind11使用するものは次のとおりです。
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/include/pybind11/eigen.h#L195 -L208
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/tests/test_eigen.py#L185
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/tests/test_numpy_array.py#L290