Numpy: Ketik petunjuk / anotasi (PEP 484) untuk ndarray, dtype, dan ufunc

Saya tidak berpikir ada yang memikirkannya. Mungkin Anda ingin? :-)

Saya juga akan menyarankan jika Anda ingin menindaklanjuti hal ini, kami menutup masalah gh dan memindahkan diskusi ke milis, karena ini lebih cocok untuk diskusi desain terbuka.

Setelah mendapatkan jawaban ini di SO, saya telah memutuskan untuk menutup masalah tersebut.

Untuk lebih jelasnya, kami sebenarnya tidak memiliki keberatan untuk mendukung fitur python baru yang keren atau apa pun (sebaliknya); hanya saja kami adalah sukarelawan yang menjalankan proyek tanpa banyak sumber daya, jadi hal-hal hanya terjadi jika ada orang yang tertarik untuk melakukannya.

Milis biasanya merupakan tempat terbaik jika Anda mencoba untuk mulai mengerjakan sesuatu atau berharap merekrut beberapa orang yang tertarik untuk membantu.

Terima kasih, @njsmith. Saya memutuskan untuk mulai di sini karena pelacakan masalah yang lebih teratur, dibandingkan dengan milis yang tidak terstruktur (saya mencari tag 'permintaan fitur', di antara fitur lainnya ...)

Karena orang yang menjawab saya di SO kembali kepada saya dengan solusi yang layak, saya memutuskan untuk meninggalkan masalah tersebut.
Mungkin dokumentasi Numpy harus diperbarui untuk menyertakan jawabannya (harap pastikan untuk memberinya kredit jika Anda melakukannya).

Terima kasih lagi!

Hallo teman-teman! Saya hanya ingin tahu apakah ada kemajuan dalam masalah ini. Terima kasih.

Ada beberapa diskusi tentang itu di milis di sini .

Saya membuka kembali masalah ini bagi mereka yang tertarik untuk membahasnya lebih lanjut.

Saya pikir ini pasti akan diinginkan untuk NumPy, tetapi memang ada beberapa aspek rumit dari NumPy API untuk mengetik untuk disortir, seperti bagaimana NumPy saat ini menerima objek sewenang-wenang dalam konstruktor np.array (meskipun kami ingin bersihkan ini, lihat https://github.com/numpy/numpy/issues/5353).

Beberapa pekerjaan bagus sedang dilakukan di sini: https://github.com/machinalis/mypy-data

Ada diskusi tentang apakah akan mendorong pekerjaan ke atas ke numpy atau mengetik: https://github.com/machinalis/mypy-data/issues/16

CC @rocklin

Ini benar-benar akan menjadi tambahan yang bagus untuk NumPy. Apa langkah selanjutnya untuk mendorong ini ke typeshed atau NumPy? Bahkan rintisan yang tidak lengkap akan berguna dan saya senang membantu dengan sedikit arahan?

@henryJack Tempat terbaik untuk memulai mungkin adalah perkakas:

Kemudian, mulailah dengan anotasi yang sangat minimal dan kita dapat melanjutkan dari sana. Secara khusus, saya akan melewatkan anotasi dtype untuk saat ini karena kita tidak memiliki cara yang baik untuk menentukannya (yaitu, lakukan hanya ndarray , bukan ndarray[int] ).

Jika bermanfaat, saya memiliki versi anotasi alternatif yang telah saya tulis untuk digunakan di Google dan dapat menjadi sumber terbuka. Tapi kami memiliki sistem build unik kami sendiri dan melakukan pemeriksaan jenis dengan pytype , jadi kemungkinan akan ada quirks yang memindahkannya ke upstream.

Saya kira satu-satunya cara untuk menguji penjelasan untuk benar-benar menjalankan mypy pada cuplikan kode sampel dan memeriksa hasilnya?

Apakah lebih baik jika anotasi diintegrasikan dengan kode atau sebagai rintisan terpisah?

Saya kira kita juga harus belajar dari dropbox dan panda bahwa kita harus mulai dengan daun basis kode versus struktur data inti?

@ sepatu figure out how we can integrate basic type annotations
Tidak hanya menempatkan https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi di direktori dasar modul numpy melakukan hal itu .. Dalam beberapa jenis versi eksperimental setidaknya

Apakah lebih baik jika anotasi diintegrasikan dengan kode atau sebagai rintisan terpisah?

Terintegrasi dengan kode akan menyenangkan, tapi saya rasa itu belum layak untuk NumPy. Bahkan dengan versi string komentar dari anotasi tipe, kita perlu mengimpor dari typing pada Python 2, dan menambahkan ketergantungan ke NumPy cukup banyak.

Selain itu, sebagian besar struktur dan fungsi data inti (hal-hal seperti ndarray dan array ) ditentukan dalam modul ekstensi, bagaimanapun juga kita perlu menggunakan stub.

Tidak hanya menempatkan https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi di direktori dasar modul numpy melakukan hal itu .. Dalam beberapa jenis versi eksperimental setidaknya

Ya, saya pikir itu sudah cukup untuk kode eksternal. Tapi bagaimana mypy menangani pustaka dengan anotasi tipe tidak lengkap?

Jika memungkinkan, kami dapat memberi anotasi numpy.core.multiarray secara langsung, bukan hanya di tingkat teratas. ( multiarray adalah modul ekstensi di mana tipe inti NumPy seperti ndarray didefinisikan.) Saya pikir ini akan memungkinkan NumPy sendiri untuk menggunakan pemeriksaan tipe untuk beberapa modul murni-Python-nya.

Saya penasaran, apa jenis np.empty(shape=(5, 5), dtype='float32') ?

Apa tipe np.linalg.svd ?

Saya pikir @kjyv telah mencoba mendefinisikannya.

np.empty : https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi#L523
np.linalg.svd : https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/linalg/__init__.pyi#L13

Sepertinya tipe diparameterisasi, apakah ini dengan dtype mereka? Apakah mungkin juga untuk membuat parameter dengan dimensi atau bentuknya? Seberapa canggih modul pengetikan Python mendukung?

Ya, mereka ditentukan oleh dtype mereka. Saya bukan ahli dalam modul pengetikan tetapi saya pikir Anda bisa saja memiliki tipe ndarray yang mewarisi Generic[dtype, int] untuk membuat parameter pada ndim . Saya yakin itulah yang dilakukan Julia. Saya tidak yakin apakah Anda dapat dengan mudah membuat parameter pada bentuk. Saya juga tidak yakin manfaat apa yang akan dibawa atau mengapa tidak dilakukan seperti itu sejak awal.

Dapatkah seseorang menggunakan dtypes numpy dalam parameter dtype atau dapatkah ini hanya mengetik
jenis modul?

Juga aneh bahwa numpy.empty mengembalikan array tipe Any. saya menduga
sulit untuk menghubungkan dan mengambil tipe dari dtype = nilai kata kunci?

Pada 1 Sep 2017 18:42, "Jacques Kvam" [email protected] menulis:

Ya, mereka ditentukan oleh dtype mereka. Saya bukan ahli dalam mengetik
modul tetapi saya pikir Anda hanya bisa memiliki tipe ndarray mewarisi Generic [dtype,
int] untuk membuat parameter pada ndim. Saya yakin itulah yang dilakukan Julia. Saya tidak
yakin jika Anda dapat dengan mudah membuat parameter pada bentuk. Saya juga tidak yakin tentang apa
manfaat yang akan membawa atau mengapa tidak dilakukan itu sebabnya di tempat pertama.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
.

Anda dapat menggunakan dtypes numpy, kita hanya perlu mendefinisikannya. Itu dilakukan di sini dengan floating dengan np.std.

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

Saya tidak yakin, saya rasa itu tidak mungkin. Saya tidak berpikir Anda dapat mengubah tipe keluaran berdasarkan nilai argumen. Saya pikir yang terbaik yang bisa kita lakukan adalah membebani fungsi dengan semua jenis spesialisasi yang akan kita pedulikan.

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

Pilihan lain mungkin untuk memperkenalkan beberapa alias yang diketik-ketat, jadi np.empty[dtype] adalah fungsi dengan tanda tangan (ShapeType) -> ndarray[dtype] .

Sudah ada beberapa preseden untuk ini dengan fungsi np.cast[dtype](x)

@jwkvam Oke, jadi mungkin penjelasan dtype bisa dilakukan - Saya baru saja menyarankan untuk mulai dari yang sederhana dan dari sana.

Saya pikir TypeVar mungkin dapat digunakan sebagai pengganti kelebihan beban, mungkin:

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

Jika saya memahami ini dengan benar, ini berarti empty(np.float64) -> ndarray[np.float64] .

Ini juga akan luar biasa untuk dapat mengetik cek informasi bentuk dan dimensi, tetapi menurut saya tipe checker saat ini tidak sesuai dengan tugas. Generic[int] adalah kesalahan, misalnya - argumen ke Generic diperlukan untuk menjadi contoh TypeVar :
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

Kami juga perlu mengungkapkan tanda tangan yang melibatkan dimensi. Misalnya, np.expand_dims maps ndim -> ndim+1 .

Saya kira satu pendekatan yang akan berhasil adalah mendefinisikan kelas untuk setiap bilangan bulat non-negatif, misalnya, Zero , One , Two , Three , .. . dan kemudian tentukan kelebihan beban untuk masing-masing. Itu akan melelahkan dengan sangat cepat.

Di TensorFlow, tf.Dimension() dan tf.TensorShape() memungkinkan Anda mengekspresikan bentuk secara statis. Tapi itu bukanlah sesuatu yang dilakukan dalam sistem tipe. Sebaliknya, setiap fungsi memiliki helper yang terkait dengannya yang menentukan bentuk output statis dari bentuk input dan argumen non-tensor apa pun. Saya pikir kita akan membutuhkan sesuatu yang serupa jika kita berharap melakukan ini dengan NumPy, tetapi tidak ada sistem pengetikan Pythons yang menyarankan fleksibilitas semacam ini.

@shoyer Saya mengerti, ya itu mengecewakan. Saya bisa meretas yang berikut ini

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

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

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

Tapi saya tidak berpikir itu mengarah ke mana pun ...

Sepertinya teladan Anda berhasil! Sepertinya itu bekerja lebih baik tanpa batasan jenis. Saya dapat menguji tipe-tipe seperti str . Saya harus menghapus argumen default, tidak tahu bagaimana cara membuatnya bekerja.

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

dan kode

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

saya mendapat

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

Saya sedikit bingung karena jika saya menukar tipe:

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

Saya tidak mendapatkan kesalahan. Meskipun menurut saya tidak ada yang ditandai sebagai kovarian.

Meskipun sistem tipenya tidak secanggih yang kami inginkan. Apakah menurut Anda itu masih sepadan? Satu manfaat yang saya hargai adalah penyelesaian kode yang lebih baik melalui jedi.

Saya sedikit bingung karena jika saya menukar tipe:

Saya yakin masalah di sini adalah bahwa int instance secara implisit dianggap valid untuk penjelasan float . Lihat catatan di menara numerik di PEP pengetikan:
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

Saya pikir ini dapat dihindari jika kita bersikeras pada jenis skalar NumPy daripada jenis Python generik untuk penjelasan, misalnya, np.ndarray[np.integer] daripada np.ndarray[int] .

Ini sebenarnya sedikit lebih mudah dari yang saya kira karena TypeVar memiliki argumen bound . Jadi merevisi contoh saya:

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

Saya harus menghapus argumen default, tidak tahu bagaimana cara membuatnya bekerja.

Saya tidak yakin apa yang Anda maksud di sini?

Saya baru saja mencoba menyandikan nilai default dtype di rintisan. Mereka melakukannya di repo mypy-data.

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

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

Mengikuti contoh Anda, saya tidak bisa membuat mypy bekerja dengan argumen default untuk dtype. Saya mencoba dtype: Type[D]=float dan dtype: Type[D]=Type[float] .

Saya pikir dtype juga perlu menjadi tipe generik, dan kemudian Anda perlu menyetel nilai default ke subkelas generik numpy seperti np.float64 daripada float , misalnya,

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

Itu tidak benar. D == type(dtype.type) == type , jadi parameterisasi tipe Anda tidak berguna, karena satu-satunya parameter yang digunakan adalah D = type .

@ eric-wieser ups, sepertinya sudah diperbaiki sekarang.

Ada beberapa diskusi terkait tentang pelacak masalah mypy (kebanyakan python / mypy # 3540). Di sana, kami melihat masalah utamanya adalah bahwa array numpy secara konseptual menyertakan dimensinya dalam tipenya, dan sistem tipe saat ini tidak benar-benar mendukungnya. Jika proyek mypy atau typeshed dapat membantu membuat pengetikan berfungsi untuk numpy, beri tahu kami!

Ada beberapa diskusi terkait tentang pelacak masalah mypy (kebanyakan python / mypy # 3540). Di sana, kami melihat masalah utamanya adalah bahwa array numpy secara konseptual menyertakan dimensinya dalam tipenya, dan sistem tipe saat ini tidak benar-benar mendukungnya. Jika proyek mypy atau typeshed dapat membantu membuat pengetikan berfungsi untuk numpy, beri tahu kami!

Saya bisa membayangkan mengkodekan lebih banyak atau lebih sedikit informasi dalam tipe parametrized di sini. Misalnya array seperti np.empty((2, 3)) bisa dari salah satu tipe berikut:

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

@JelleZijlstra apa pendapat Anda di sini tentang alat seperti mypy yang kemungkinan besar akan dapat menangani? Seberapa canggih kita bisa?

Tampaknya cukup jelas bahwa pekerjaan yang signifikan dalam sistem tipe akan dibutuhkan untuk mendukung bentuk dan dimensi. Saya akan menyambutnya (dan baru saja menuliskan banyak ide dalam python / mypy # 3540), tetapi untuk saat ini mari kita sebut itu di luar ruang lingkup untuk NumPy. Hanya mendapatkan ndarray[float64] bekerja tampaknya cukup sulit, mengingat hierarki tipe numpy yang kompleks dan tantangan tipe generik.

Ya, menurut saya langkah pertama adalah mendapatkan dukungan pengetikan dasar untuk numpy (dan Pandas dan sklearn), tanpa mempertimbangkan bentuk dan batasan tambahan lainnya pada jenis tersebut.

Masalah dengan batasan tambahan lainnya adalah tidak cukup hanya mendeskripsikan dtype (shape = 5,6), tetapi harus ada bahasa untuk mendeskripsikan batasan pada bentuk itu. Anda dapat membayangkan bahwa Anda ingin menentukan fungsi yang hanya menerima bentuk persegi numpy sebagai masukan, atau yang satu dimensinya harus 2x dari yang lain.

Hal seperti itu dilakukan dalam proyek kontrak .

Saya juga berpikir bahwa PEP 472 akan sangat bagus untuk didukung di sini, karena dengan demikian orang dapat melakukan hal-hal seperti Array[float64, ndim=2] .

Memang, PEP 472 akan bagus untuk mengetik, meskipun ini mungkin salah satu perbaikan yang lebih mudah untuk mewujudkannya! (Silakan ping saya jika Anda tertarik untuk memulai kembali diskusi seputar ini, karena menurut saya ada juga kasus penggunaan yang menarik untuk dimensi bernama dalam pengindeksan.)

Saya tidak yakin bagaimana cara saya berkontribusi, tetapi menurut saya ini akan menjadi fitur yang luar biasa karena berbagai alasan. Tapi, kita menuju ke arah itu, maka sepertinya [] hanya menjadi cara yang berbeda untuk memanggil sebuah objek. Jadi object(*args, **kwargs) melakukan sesuatu, object[*args, **kwargs] sesuatu yang lain, dan kemudian kita bahkan dapat menggeneralisasi dan juga memiliki object{*args, **kwags} dan object<*args, **kwargs> . ;-)

@mitar : ndarray[float].constrain(ndim=2) . Kami sudah memiliki banyak sintaks yang tersedia, dan tidak seperti dekorator, anotasi tidak memiliki batasan

Saya sebenarnya mencoba sintaks berikut: ndarray[float](ndim=2) , jadi membebani secara berlebihan bahwa pada obat generik __call__ mengembalikan lagi sebuah kelas, dan bukan turunan dari sebuah kelas. Tetapi menjadi rumit untuk tipe yang bukan generik.

Saya pikir masalah utamanya adalah dengan ndarray[float] dukungan, karena ndarray[float] bukanlah sesuatu yang benar-benar ada di ndarray , seseorang harus mengubah ndarray itu sendiri, yang mana Saya tidak yakin apakah prinsip umum yang baik untuk dilakukan (mengubah kode upstream untuk mendukung pengetikan yang lebih baik).

Satu pendekatan lain bisa jadi memiliki tipe variabel tipe baru, ConstrainedTypeVar , di mana Anda dapat melakukan sesuatu seperti ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) atau sesuatu seperti itu, dan kemudian Anda akan menggunakan A sebagai var di tanda tangan fungsi. Tapi ini menjadi sangat bertele-tele.

Saya menulis dokumen dengan beberapa ide tentang seperti apa bentuk array pengetikan dengan penyiaran dan gagasan tentang identitas dimensi.

Ide intinya meliputi:

1. Menambahkan primitif DimensionVar yang memungkinkan identitas simbolik untuk dimensi array
2. Mengenali ... ( Ellipsis ) sebagai penyiaran array yang menunjukkan.

Misalnya, untuk mengetik 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]: ...

Ini akan cukup untuk memungkinkan pengetikan ufunc umum . Lihat dokumen untuk detail dan contoh lebih lanjut.

Solusi yang mungkin untuk mendukung dtypes dan shape, jika kita sudah memilih untuk tetap membedakan NDArray dan ndarray :

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

Hanya berpikir, apakah masuk akal juga memiliki pintasan seperti ini?

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

- yang dapat menyederhanakan sejumlah tanda tangan, terutama dalam kode downstream.

@aldanor Saya rasa maksud Anda NDArray.shape[:, :] ( ... berarti "nol atau lebih dimensi", yang kurang tepat dalam konteks ini). Tapi ya, itu terlihat masuk akal.

Pembaruan cepat saat mengetik untuk dtypes: Saya menulis modul mainan menggunakan pendekatan yang saya jelaskan di atas yang menggunakan np.generic subclass dengan Generic untuk parameterisasi ndarray / dtype jenis .

Ini sebagian besar tampaknya bekerja dengan mypy seperti yang saya harapkan, termasuk jenis inferensi yang setara dengan np.empty(..., dtype=np.float32) . Itu gagal untuk menangkap salah satu kesalahan tipe disengaja saya yang melibatkan tipe Union (Saya akan mengajukan laporan bug nanti).

Saya pikir ini mungkin cukup baik untuk tipe-tipe. Tanpa dukungan pengetikan untuk nilai literal, kami tidak dapat melakukan inferensi tipe dengan dtype yang ditentukan sebagai string ( dtype='float32' ). Mungkin yang lebih bermasalah, itu juga tidak menangani jenis inferensi dari jenis Python seperti dtype=float . Tapi tipe ini bisa ambigu (mis., dtype=int dipetakan ke np.int64 di Linux dan np.int32 di Windows), jadi mungkin lebih baik menggunakan tipe generik eksplisit. Tidak apa-apa jika jenis inferensi tidak berfungsi dalam setiap kasus yang memungkinkan, selama spesifikasi dtype=float disimpulkan sebagai dtype Any daripada menimbulkan kesalahan.

Tetapi tipe ini bisa ambigu (misalnya, dtype = int memetakan ke np.int64 di Linux dan np.int32 di Windows)

Itu tidak ambigu - dalam semua kasus, itu memetakan ke np.int_ , yang merupakan tipe C long .

Saya telah menulis milis untuk mendapatkan konsensus tentang penulisan jenis rintisan untuk NumPy dalam paket terpisah:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

Luar biasa, terima kasih @shoyer !

Sesuai konsensus di milis, saya ingin menyatakan https://github.com/numpy/numpy_stubs terbuka untuk bisnis!

Kami akan mulai dengan anotasi dasar (tidak ada dukungan dtype). Jika ada yang ingin mengumpulkan PR dasar untuk menambahkan perancah PEP 561 untuk repo yang akan dihargai!

YA, YA, 1000X YA!

Perhatian untuk siapa pun yang mengikuti masalah ini: Saya telah membuka dua masalah pada pelacak python / pengetikan:

• ndarray mengetik secara umum (https://github.com/python/typing/issues/513)
• sintaks untuk mengetik ndarray (https://github.com/python/typing/issues/516)

Berapa waktu rilis yang diharapkan untuk fitur pengetikan?
Apakah ada alasan untuk mencoba mempertahankan kompatibilitas 2.7?
Sebuah komentar awal menyebutkan kesulitan dalam berintegrasi dengan python 2. Sejak itu, numpy tampaknya telah mengubah pendiriannya.

Hal-hal adalah target yang bergerak, saya tahu, tetapi apakah masuk akal untuk menargetkan sesuatu seperti Python 3.4-3.6?

Berapa waktu rilis yang diharapkan untuk fitur pengetikan?

Ada beberapa diskusi tentang ini (generik integer alias tipe dependen sederhana) di PyCon, saya akan menulis proto-PEP berdasarkan diskusi ini dan dokumen asli yang ditulis oleh @shoyer segera. Target saya adalah membuat PEP ditulis, diimplementasikan di mypy dan diterima tepat waktu untuk Python 3.8 beta 1 (juga kemungkinan besar backport jenis baru berikutnya di typing untuk Python 2)

@hmaarrfk untuk menulis anotasi jenis untuk NumPy itu sendiri, kami mulai melakukannya di repositori terpisah: https://github.com/numpy/numpy-stubs. Anda seharusnya dapat menginstal dan menggunakan stub tersebut dalam kondisi saat ini (dengan versi terbaru mypy), tetapi masih jauh dari selesai. Bantuan akan sangat dihargai!

Tentu, saya senang membantu jika saya bisa, dan saya melihat repositori. Saya hanya tahu bahwa hal-hal ini membutuhkan waktu.
Saya melihat repo dan melihat komit menyebutkan kompatibilitas 2.7, itulah sebabnya saya bertanya.

Waktu rilis Python 3.8 beta adalah pertengahan 2019 . Numpy menyebutkan bahwa mereka akan menghentikan fitur baru pada akhir 2018 .

Mengetik tampaknya merupakan fitur yang "bagus untuk dimiliki" untuk numpy, bukan "harus dimiliki". Dengan demikian, menargetkan dua bahasa tampaknya agak sulit, terutama jika fitur tersebut akan mulai muncul jauh melampaui batas waktu dukungan numpy sendiri.

Saya akan tertarik untuk membaca apa yang dikatakan @ilevkivskyi di PEP.

@hmaarrfk Anda menyampaikan hal yang baik tentang dukungan Python 2.7. Sejujurnya, saya belum memikirkannya sepenuhnya. Saya berharap bahwa kami pada akhirnya akan menjatuhkannya, tetapi mungkin tidak sebelum mypy sendiri menjatuhkan dukungan Python 2.7, mengingat bahwa kasus penggunaan utama untuk mengetik adalah menulis kode yang kompatibel dengan Python 2/3.

Untuk saat ini, tampaknya tidak memerlukan banyak kompromi untuk mendukung Python 2 dalam anotasi tipe kami, jadi saya dengan senang hati membiarkannya, terutama karena itu berasal dari kontributor yang jelas tertarik padanya.

Saya ingin menyodok ini lagi untuk melihat apakah diskusi telah berkembang, terutama mengenai informasi bentuk petunjuk tipe, yang akan sangat berguna dalam banyak aplikasi saya. Apakah ada pelacak status atau apakah ini bukan prioritas yang cukup tinggi untuk memiliki sumber daya yang didedikasikan untuk itu?

Di transonic , sebuah proyek untuk menggeneralisasi akselerator numpy, kami memiliki sintaks petunjuk tipe sebagai alternatif untuk anotasi Pythran yang menggunakan komentar . Ini tidak bekerja dengan baik dengan mypy sekarang, tapi saya ingin tahu apakah itu berguna. Lihat contoh: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

Jika ini berguna untuk masalah ini, saya akan menyebutkan bahwa saya telah membuat alat untuk mengonversi docstrings untuk mengetik komentar: https://pypi.org/project/doc484/

Saya menggunakan ini dengan pra-komit di beberapa proyek untuk menjaga dokumen tetap sinkron dengan jenis komentar.

Anda masih perlu mengonversi jenis di docstrings Anda agar sesuai dengan PEP484.

Halo semuanya,

Saya ingin melakukan bagian saya, jadi saya membagi repo dan mulai menambahkan petunjuk tipe. Ide saya adalah bekerja dari bawah ke atas, jadi mulailah dengan fungsi "sederhana" dan lanjutkan ke atas dari sana. (Dimulai dengan buah yang tergantung rendah)

Misalnya di _string_helpers.py , saya menambahkan petunjuk tipe ke beberapa variabel dan fungsi.

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

Apa pendapat Anda tentang ini?

Saya akan merekomendasikan melakukan sedikit dan membuka PR untuk mendapatkan komentar. numpy menargetkan ular sanca yang lebih tua (3.5 anotasi yang diperkenalkan, IIRC) dan ini akan merusak build tersebut, jadi mungkin periksa untuk menulis file .pyi atau periksa dokumen mypy untuk melihat apakah ada lebih banyak panduan tentang praktik terbaik.

Sejauh ini kami telah melakukan anotasi di numpy-stubs terpisah
repositori, tetapi ini merupakan proses yang lambat.

Pada Kamis, 14 November 2019 pukul 09.57 Notifikasi Ben [email protected] menulis:

Saya akan merekomendasikan melakukan sedikit dan membuka PR untuk mendapatkan komentar. numpy
menargetkan ular sanca yang lebih tua (3.5 anotasi yang diperkenalkan, IIRC) dan ini
akan merusak build tersebut, jadi mungkin akan mempertimbangkan untuk menulis file .pyi atau check
dokumen mypy untuk melihat apakah ada lebih banyak panduan tentang praktik terbaik.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFVreXG43
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

@ bsamuel-ui numpy saat ini membutuhkan Python 3.5+, dan NEP-29 [1] menyatakan tidak masalah untuk mengubahnya menjadi 3.6+
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

Anotasi (untuk argumen fungsi dan tipe kembalian) sebenarnya didukung di semua versi Python 3; 3.6 hanya memperkenalkan anotasi variabel. Pada Python 3 versi awal (<3.5) Anda harus menggunakan backport dari modul typing .

Saya telah menambahkan permintaan tarik dengan file .pyi pertama saya. Ini perlu beberapa perbaikan tetapi alangkah baiknya jika kalian bisa melihatnya sehingga saya bisa mendapatkan umpan balik awal

Seperti yang disebutkan di gh-14905, kami memiliki awal perpustakaan rintisan di https://github.com/numpy/numpy-stubs. Akan sangat bagus untuk menjalankannya dengan tes yang tepat dan kemudian kita dapat memutuskan cara terbaik untuk mengemasnya atau menggabungkannya menjadi numpy / numpy proper.

@ Mattip saya buruk. Saya akan menghapus permintaan tarik dari numpy dan menambahkan yang baru ke numpy-stubs

masih terbuka, tapi saya yakin numpy sudah mendukungnya di versi master

Hai,
Saya mencoba untuk mendefinisikan alias tipe untuk vektor 3d, jadi sebuah array numpy bentuk (3,) dari dtype int32.

(Saya tahu saya bisa mengetik petunjuk dengan np.ndarray tetapi bagaimana saya bisa lebih spesifik? Saya membaca di sini semua dan tidak mengerti, saya juga mencari tutorial tentang cara menggunakan tipe numpy untuk mengetik dengan Python tetapi tidak temukan apa saja.)

Sepertinya mungkin untuk menulis:

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

Saya mencoba melakukan:

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

Apakah ini cara yang benar untuk dilakukan?

Bisakah seseorang di sini menunjukkan tutorial atau contoh?

Juga, saya menemukan repo ini yaitu "Type hints for Numpy": https://github.com/ramonhagenaars/nptyping

Akankah Numpy mengintegrasikan ini?
@rumahsakitotak

@tiptip

Seperti yang disebutkan di gh-14905, kami memiliki awal perpustakaan rintisan di https://github.com/numpy/numpy-stubs.

Sepertinya ini telah digabungkan ke dalam repo utama. Apakah ini sudah dirilis, atau sudah ada di peta jalan? Mencoba memutuskan apakah kita harus menjelajahi sesuatu dari pihak ketiga seperti https://github.com/ramonhagenaars/nptyping atau (idealnya) menunggu / menggunakan petunjuk jenis yang didukung secara resmi.

Terima kasih.

Kami telah menggabungkan banyak numyp-stubs ke dalam cabang pengembangan. Anda dapat mengikuti perkembangannya dengan mencari label pengetikan statis . Semoga ini menjadi bagian dari rilis berikutnya. Anda dapat mencoba apa yang saat ini digabungkan dengan menggunakan versi HEAD dari numpy. Kami selalu mencari kontributor: tinjauan konstruktif, dokumentasi, dan komentar tentang masalah dan permintaan tarik adalah beberapa cara untuk membantu.

(Saya tahu saya bisa mengetik petunjuk dengan np.ndarray tetapi bagaimana saya bisa lebih spesifik? Saya membaca di sini semua dan tidak mengerti, saya juga mencari tutorial tentang cara menggunakan tipe numpy untuk mengetik dengan Python tetapi tidak temukan apa saja.)

Ada banyak minat di bidang ini, tetapi pengetikan yang lebih spesifik (tipe dan dimensi) untuk array NumPy belum didukung.

@ GilShoshan94 FWIW Saya telah mengajukan https://github.com/ramonhagenaars/nptyping/issues/27

Juga FWIW, inilah yang digunakan pybind11 untuk tanda tangan tipe "anotasi" di string __doc__ untuk kelebihan beban:
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