Numpy: اكتب تلميح / تعليق توضيحي (PEP 484) لـ ndarray و dtype و ufunc

لا أعتقد أن أي شخص يفكر في ذلك. ربما ترغب في ذلك؟ :-)

سأقترح أيضًا أنه إذا كنت ترغب في متابعة هذا الأمر ، فإننا نغلق مشكلة gh وننقل المناقشة إلى القائمة البريدية ، نظرًا لأنها أكثر ملاءمة لمناقشات التصميم المفتوحة.

بعد الحصول على هذه الإجابة على SO ، قررت إغلاق المشكلة.

لكي نكون واضحين ، ليس لدينا أي اعتراض فعليًا على دعم ميزات Python الجديدة الرائعة أو أي شيء (بالأحرى العكس) ؛ كل ما في الأمر أننا متطوعون يديرون مشروعًا بدون موارد كثيرة ، لذلك لا تحدث الأشياء إلا إذا تقدم شخص مهتم للقيام بذلك.

عادةً ما تكون القائمة البريدية هي أفضل مكان إذا كنت تحاول البدء في العمل على شيء ما أو تأمل في تجنيد بعض الأشخاص المهتمين الآخرين للمساعدة.

شكرا ياnjsmith. قررت أن أبدأ هنا بسبب تتبع المشكلات الأكثر تنظيماً ، بدلاً من قائمة بريدية غير منظمة (كنت أبحث عن علامة "طلب ميزة" ، من بين ميزات أخرى ...)

نظرًا لأن الرجل الذي أجاب علي على SO عاد إلي بحل قابل للتطبيق ، قررت ترك الأمر.
ربما يجب تحديث وثائق Numpy لتشمل إجابته (يرجى التأكد من منحه الائتمان إذا فعلت ذلك).

شكرا لك مرة أخرى!

مرحبا يا شباب! كنت فقط أتساءل إذا كان هناك أي تقدم في هذه المسألة. شكر.

هناك بعض النقاش حوله في القائمة البريدية هنا .

أنا أعيد فتح هذه القضية لأولئك الذين يرغبون في مناقشتها بشكل أكبر.

أعتقد أن هذا سيكون مرغوبًا بالتأكيد لـ NumPy ، ولكن هناك بالفعل بعض الجوانب الصعبة في NumPy API للكتابة للفرز ، مثل كيفية قبول NumPy حاليًا للكائنات العشوائية في المُنشئ np.array (على الرغم من أننا نريد قم بتنظيف هذا ، راجع https://github.com/numpy/numpy/issues/5353).

يتم إجراء بعض الأعمال الجيدة هنا: https://github.com/machinalis/mypy-data

هناك نقاش حول ما إذا كان يجب دفع العمل إلى المنبع أو الطباعة: https://github.com/machinalis/mypy-data/issues/16

CCmrocklin

سيكون هذا حقًا إضافة رائعة لـ NumPy. ما هي الخطوات التالية لدفع هذا الأمر إلى الكتابة أو NumPy؟ حتى كعب الروتين غير المكتمل سيكون مفيدًا وأنا سعيد بالمساعدة في القليل من التوجيه؟

henryJack ربما يكون أفضل مكان للبدء هو الأدوات: اكتشف كيف يمكننا دمج التعليقات التوضيحية من النوع الأساسي في مستودع NumPy (واختبارها بشكل مثالي) بطريقة تعمل مع mypy وتدعم إضافتها بشكل تدريجي.

بعد ذلك ، ابدأ بأقل قدر ممكن من التعليقات التوضيحية ويمكننا الانتقال من هناك. على وجه الخصوص ، سأتخطى التعليقات التوضيحية من النوع dtype في الوقت الحالي نظرًا لأنه ليس لدينا طريقة جيدة لتحديدها (على سبيل المثال ، استخدم فقط ndarray ، وليس ndarray[int] ).

إذا كان ذلك مفيدًا ، فلدي نسخة بديلة من التعليقات التوضيحية التي كتبتها للاستخدام في Google ويمكنني فتح المصدر. لكن لدينا نظام بناء فريد خاص بنا ونقوم بفحص النوع باستخدام

أفترض أن الطريقة الوحيدة لاختبار التعليقات التوضيحية لتشغيل 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 حتى الآن. حتى مع إصدار سلسلة التعليقات من نوع التعليقات التوضيحية ، سنحتاج إلى الاستيراد من typing على Python 2 ، وإضافة التبعيات إلى NumPy بعيدًا عن الطاولة.

أيضًا ، يتم تحديد معظم هياكل ووظائف البيانات الأساسية (أشياء مثل ndarray و array ) في وحدات الامتداد ، سنحتاج إلى استخدام بذرات هناك على أي حال.

لن يؤدي مجرد وضع https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi في الدليل الأساسي للوحدة الرقمية إلى القيام بذلك بالضبط .. في إصدار تجريبي من نوع ما على الأقل

نعم ، أعتقد أن هذا سيكون كافياً للكود الخارجي. ولكن كيف يتعامل mypy مع المكتبات ذات التعليقات التوضيحية غير المكتملة؟

إذا كان ذلك ممكنًا ، فقد نعلق على numpy.core.multiarray مباشرة ، وليس فقط في المستوى الأعلى. ( multiarray هي وحدة الامتداد حيث يتم تعريف أنواع NumPy الأساسية مثل ndarray .) أعتقد أن هذا سيسمح لـ NumPy نفسها بالاستفادة من التحقق من النوع لبعض وحدات Python النقية.

لدي فضول ، ما هو نوع np.empty(shape=(5, 5), dtype='float32') ؟

ما هو نوع np.linalg.svd ؟

أعتقد أن kjyv قد طعنه في تحديد هؤلاء.

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

يبدو أن الأنواع محددة ، هل هذا مع نوع dtype الخاص بهم؟ هل من الممكن أيضًا تحديد أبعادها أو شكلها؟ ما مدى التطور الذي تدعمه وحدة الكتابة في Python؟

نعم هم معلمات حسب نوعهم. لست خبيرًا في وحدة الكتابة ، لكنني أعتقد أنه يمكنك فقط الحصول على نوع ndarray يرث Generic[dtype, int] لوضع معلمات على ndim . أعتقد أن هذا ما تفعله جوليا. لست متأكدًا مما إذا كان يمكنك بسهولة تحديد المعلمات على الشكل. ولست متأكدًا من الفوائد التي ستجلبها أو لماذا لم يتم ذلك بهذه الطريقة في المقام الأول.

هل يمكن للمرء استخدام أنواع dtype numpy في معلمة dtype أو يمكن كتابة هذا فقط
أنواع الوحدات؟

كما أنه من الغريب أن يقوم numpy.empty بإرجاع مصفوفة من النوع Any. اشك
من الصعب التداخل وأخذ النوع من dtype = قيمة الكلمة الرئيسية؟

في 1 سبتمبر 2017 ، 6:42 مساءً ، كتب "جاك كفام" [email protected] :

نعم هم معلمات حسب نوعهم. لست خبيرا في الكتابة
وحدة ولكن أعتقد أنه يمكنك الحصول على نوع 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
.

يمكنك استخدام dtypes numpy ، نحتاج فقط إلى تعريفها. تم ذلك هنا باستخدام floating باستخدام np.std.

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

لست متأكدًا ، لا أعتقد أنه ممكن. لا أعتقد أنه يمكنك تعديل نوع الإخراج بناءً على قيمة الوسيطة. أعتقد أن أفضل ما يمكننا فعله هو زيادة تحميل الوظيفة بكل تخصصات النوع التي نهتم بها.

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

قد يكون هناك خيار آخر وهو تقديم بعض الأسماء المستعارة ذات الكتابة الصارمة ، لذا فإن np.empty[dtype] هي وظيفة ذات توقيع (ShapeType) -> ndarray[dtype] .

هناك بالفعل بعض السوابق لهذا مع الوظيفة np.cast[dtype](x) غير العادية

jwkvam حسنًا ، لذلك ربما تكون التعليقات التوضيحية 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 .

أفترض أن إحدى الطرق التي ستنجح هي تحديد الفئات لكل عدد صحيح غير سالب ، على سبيل المثال ، Zero ، One ، Two ، Three ، .. ثم تحديد الحمولة الزائدة لكل منها. سوف يتعب ذلك بسرعة كبيرة.

في TensorFlow ، يتيح لك tf.Dimension() و tf.TensorShape() التعبير عن الأشكال بشكل ثابت. لكنه ليس شيئًا يتم إجراؤه في نظام الكتابة. بدلاً من ذلك ، تحتوي كل وظيفة على مساعد مرتبط بها يحدد الشكل الثابت للمخرجات من شكل المدخلات وأي وسيطات غير موترية. أعتقد أننا سنحتاج إلى شيء مشابه إذا كنا نأمل في القيام بذلك باستخدام NumPy ، لكن لا يوجد شيء في نظام كتابة Pythons يشير إلى هذا النوع من المرونة.

@ 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 . اضطررت إلى إزالة الحجة الافتراضية ، ولم أستطع معرفة كيفية جعل ذلك يعمل.

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)

ليس لدي أي خطأ. على الرغم من أنني لا أعتقد أن أي شيء تم تمييزه على أنه متغير.

على الرغم من أن نظام الكتابة ليس معقدًا كما نرغب. هل تعتقد أنه لا يزال يستحق ذلك؟ إحدى المزايا التي سأقدرها هي إكمال الكود بشكل أفضل من خلال جيد.

أنا في حيرة من أمري لأنني إذا قمت بتبديل الأنواع:

أعتقد أن المشكلة هنا هي أن المثيلات int تعتبر ضمنيًا صالحة للتعليقات التوضيحية float . انظر الملاحظات على برج رقمي في الكتابة PEP:
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

أعتقد أنه يمكن تجنب هذا إذا أصررنا على أنواع عددية NumPy بدلاً من أنواع Python العامة للتعليقات التوضيحية ، على سبيل المثال ، np.ndarray[np.integer] بدلاً من np.ndarray[int] .

هذا في الواقع أسهل قليلاً مما كنت أتصور لأن TypeVar له وسيطة bound . لذا مراجعة نموذجي:

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

اضطررت إلى إزالة الحجة الافتراضية ، ولم أستطع معرفة كيفية جعل ذلك يعمل.

لست متأكدًا تمامًا مما كنت ستحصل عليه هنا؟

لقد حاولت للتو ترميز القيمة الافتراضية لـ dtype في كعب الروتين. لقد فعلوا ذلك في مستودع بيانات mypy.

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 يحتاج أيضًا إلى أن يصبح نوعًا عامًا ، وبعد ذلك تحتاج إلى تعيين القيمة الافتراضية إلى فئة فرعية عامة غير متداخلة مثل np.float64 بدلاً من float ، على سبيل المثال ،

# 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 في الغالب). هناك ، ندرك أن المشكلة الرئيسية تتمثل في أن المصفوفات غير الدقيقة تتضمن أبعادها في نوعها من الناحية المفاهيمية ، وأن نظام النوع الحالي لا يدعم ذلك حقًا. إذا كان بإمكان المشاريع mypy أو التي تم طباعتها المساعدة بأي شكل من الأشكال في الحصول على عمل للكتابة ، فيرجى إخبارنا بذلك!

كانت هناك بعض المناقشات ذات الصلة حول متتبع مشكلات mypy (python / mypy # 3540 في الغالب). هناك ، ندرك أن المشكلة الرئيسية تتمثل في أن المصفوفات غير الدقيقة تتضمن أبعادها في نوعها من الناحية المفاهيمية ، وأن نظام النوع الحالي لا يدعم ذلك حقًا. إذا كان بإمكان المشاريع mypy أو التي تم طباعتها المساعدة بأي شكل من الأشكال في الحصول على عمل للكتابة ، فيرجى إخبارنا بذلك!

يمكنني أن أتخيل ترميز معلومات أكثر أو أقل في أنواع معلمات هنا. على سبيل المثال ، يمكن أن تكون مصفوفة مثل 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. يبدو أن مجرد الحصول على عمل ndarray[float64] صعب بما فيه الكفاية ، بالنظر إلى التسلسل الهرمي لنوع numpy المعقد وتحديات الأنواع العامة.

نعم ، أعتقد أن الخطوة الأولى ستكون فقط الحصول على دعم الكتابة الأساسي لـ numpy (و Pandas و sklearn) ، دون مراعاة الأشكال والقيود الإضافية الأخرى على هذه الأنواع.

تكمن المشكلة مع القيود الإضافية الأخرى في أنه لا يكفي مجرد وصف نوع dtype (الشكل = 5،6) ، ولكن يجب أن تكون هناك لغة لوصف قيد على هذا الشكل. يمكنك أن تتخيل أنك تريد تحديد وظيفة تقبل فقط الأشكال المربعة المربعة كمدخلات ، أو أحد الأبعاد حيث يجب أن يكون أحد الأبعاد 2x الآخر.

شيء من هذا القبيل تم القيام به في مشروع العقود .

أعتقد أيضًا أن دعم PEP 472 سيكون رائعًا هنا ، لأنه بعد ذلك يمكن للمرء فعل أشياء مثل Array[float64, ndim=2] .

في الواقع ، سيكون PEP 472 رائعًا للكتابة ، على الرغم من أنه من المحتمل أن يكون أحد الحلول الأسهل لتحقيق ذلك! (يرجى الاتصال بي إذا كنت مهتمًا بإعادة بدء المناقشة حولها ، حيث أعتقد أن هناك أيضًا حالات استخدام مقنعة للأبعاد المسماة في الفهرسة.)

لست متأكدًا من كيفية المساهمة ، لكنني أعتقد بالتأكيد أنها ستكون ميزة رائعة لأسباب متعددة. لكن ، نحن نسير في هذا الاتجاه ، إذًا يبدو أن [] يصبح مجرد طريقة مختلفة لاستدعاء كائن. لذا فإن 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[float] ليس شيئًا موجودًا بالفعل في ndarray ، يجب على المرء تغيير ndarray نفسه ، والذي لست متأكدًا من أنه مبدأ عام جيد يجب القيام به (تغيير كود المنبع لدعم الكتابة بشكل أفضل).

يمكن أن يكون أحد الأساليب الأخرى هو الحصول على نوع جديد من متغيرات النوع ، ConstrainedTypeVar ، حيث يمكنك القيام بشيء مثل ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) أو شيء من هذا القبيل ، وبعد ذلك يمكنك استخدام A باعتباره var في توقيع الوظيفة. لكن هذا يصبح مطولاً للغاية.

لقد كتبت مستندًا يحتوي على بعض الأفكار حول الشكل الذي يمكن أن تبدو عليه أشكال المصفوفة عند البث ومفهوم هوية البعد.

تشمل الأفكار الأساسية ما يلي:

1. إضافة 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]: ...

ستكون هذه كافية للسماح بكتابة ufuncs المعممة . راجع المستند لمزيد من التفاصيل والأمثلة.

حل ممكن لدعم كل من dtypes والأشكال ، إذا اخترنا بالفعل الاحتفاظ بـ NDArray و ndarray مميزين:

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: لقد كتبت وحدة لعبة باستخدام الأسلوب الذي وصفته أعلاه والذي يستخدم فئات فرعية np.generic مع Generic لأنواع ndarray / dtype .

يبدو أن هذا في الغالب يعمل مع mypy كما أتوقع ، بما في ذلك استدلال النوع بما يعادل np.empty(..., dtype=np.float32) . إنه يفشل في اكتشاف أحد أخطاء النوع المتعمدة التي تتضمن نوع Union (سأقدم تقرير خطأ لاحقًا).

أعتقد أن هذا من المحتمل أن يكون جيدًا بما يكفي لـ dtypes. بدون كتابة دعم القيم الحرفية ، لا يمكننا كتابة الاستدلال بنوع محدد كسلاسل ( dtype='float32' ). ربما يكون الأمر الأكثر إشكالية ، أنه لا يتعامل أيضًا مع الاستدلال النوعي من أنواع Python مثل dtype=float . ولكن يمكن أن تكون هذه الأنواع غامضة (على سبيل المثال ، خرائط dtype=int إلى np.int64 على Linux و np.int32 على Windows) ، لذلك من الأفضل استخدام الأنواع العامة الصريحة على أي حال. لا بأس إذا كان الاستدلال النوع لا يعمل في كل الحالات الممكنة ، طالما أن المواصفات dtype=float يتم استنتاجها على أنها نوع dtype Any بدلاً من إظهار خطأ.

ولكن يمكن أن تكون هذه الأنواع غامضة (على سبيل المثال ، dtype = int خرائط إلى np.int64 على Linux و np.int32 على Windows)

هذا ليس غامضًا - في جميع الحالات ، يتم تعيين هذا إلى np.int_ ، وهو النوع C long .

لقد قمت بكتابة القائمة البريدية للحصول على إجماع حول كتابة نوع stubs لـ NumPy في حزمة منفصلة:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

مدهش ، شكرا @ shoyer !

وفقًا للإجماع على القائمة البريدية ، أود أن أعلن https://github.com/numpy/numpy_stubs مفتوحًا للعمل!

سنبدأ بالتعليقات التوضيحية الأساسية (لا يوجد دعم dtype). إذا كان أي شخص يريد تجميع علاقات عامة أساسية لإضافة سقالة PEP 561 إلى الريبو ، فسيكون ذلك موضع تقدير!

نعم ، نعم ، 1000X نعم!

تنبيه لأي شخص يتابع هذه المشكلة: لقد فتحت مشكلتين في متتبع بيثون / الكتابة:

• الكتابة ndarray بشكل عام (https://github.com/python/typing/issues/513)
• بناء الجملة للكتابة ndarray (https://github.com/python/typing/issues/516)

ما هو وقت الإصدار المتوقع لميزة الكتابة؟
هل هناك أي سبب لمحاولة الحفاظ على التوافق 2.7؟
أشار تعليق مبكر إلى صعوبة الاندماج مع بيثون 2. منذ ذلك الحين ، يبدو أن numpy قد غير موقفه.

أعلم أن الأشياء تتحرك ، لكن هل من المنطقي استهداف شيء مثل Python 3.4-3.6؟

ما هو وقت الإصدار المتوقع لميزة الكتابة؟

كان هناك العديد من المناقشات حول هذا (نوع صحيح ويعرف أيضًا باسم الأنواع التابعة البسيطة) في PyCon ، سأكتب proto-PEP بناءً على هذه المناقشات والمستند الأصلي الذي كتبه shoyer قريبًا. هدفي هو كتابة PEP وتنفيذها في mypy وقبولها في الوقت المناسب لـ Python 3.8 beta 1 (من المحتمل جدًا أيضًا أن يكون هناك منفذ خلفي لاحق للأنواع الجديدة في typing لـ Python 2)

hmaarrfk بالنسبة لكتابة التعليقات التوضيحية لنوع NumPy نفسه ، بدأنا في القيام بذلك في مستودع منفصل: https://github.com/numpy/numpy-stubs. يجب أن تكون قادرًا على تثبيت واستخدام تلك الأجزاء الجذرية في الحالة الحالية (مع أحدث إصدار من mypy) ، لكنها بعيدة عن الاكتمال. سيكون موضع تقدير المساعدة!

بالتأكيد ، يسعدني تقديم المساعدة حيث يمكنني ذلك ، ورأيت المستودع. أنا أعلم فقط أن هذه الأشياء تستغرق وقتًا.
لقد رأيت الريبو ولاحظت الالتزام المذكور في التوافق 2.7 ، ولهذا السبب سألت.

وقت إصدار بايثون 3.8 بيتا منتصف عام 2019 . ذكر Numpy أنهم سيوقفون الميزات الجديدة في نهاية عام 2018 .

يبدو أن الكتابة هي ميزة "لطيفة امتلاكها" للمكتبيين بدلاً من "لا بد من امتلاكها". على هذا النحو ، يبدو استهداف لغتين أمرًا صعبًا بعض الشيء ، خاصة إذا كانت الميزة ستبدأ في الظهور بعد الموعد النهائي للدعم الخاص بـ numpy.

سأكون مهتمًا بقراءة ما يجب أن يقوله ilevkivskyi في PEP.

hmaarrfk لقد

في الوقت الحالي ، لا يبدو أنه يتطلب العديد من التنازلات لدعم Python 2 في التعليقات التوضيحية من النوع الخاص بنا ، لذلك يسعدني تركها ، خاصةً لأنها جاءت من مساهم كان مهتمًا بها بشكل واضح.

كنت أرغب في نقش هذا مرة أخرى لمعرفة ما إذا كانت المناقشات قد تقدمت ، خاصة فيما يتعلق بمعلومات شكل تلميحات الكتابة ، والتي ستكون مفيدة بشكل خاص في الكثير من تطبيقاتي. هل يوجد متتبع حالة أم أن هذه ليست أولوية عالية بما يكفي لتخصيص أي موارد لها؟

في transonic ، وهو مشروع لتعميم المسرّعات الصغيرة ، لدينا صيغة تلميح من النوع كبديل لتعليقات Pythran التوضيحية التي تستخدم التعليقات . إنه لا يعمل بشكل جيد مع mypy في الوقت الحالي ، لكني أتساءل عما إذا كان مفيدًا. شاهد مثالاً: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

في حالة ما إذا كانت هذه المشكلة مفيدة ، سأذكر أنني قمت بعمل أداة لتحويل سلاسل المستندات لكتابة التعليقات: https://pypi.org/project/doc484/

أستخدم هذا مع الالتزام المسبق في العديد من المشاريع للحفاظ على مزامنة السلاسل مع تعليقات الكتابة.

ستظل بحاجة إلى تحويل الأنواع الموجودة في سلاسل مستنداتك لتكون متوافقة مع 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

ما رأيك بهذا؟

أوصي بعمل القليل وفتح العلاقات العامة للحصول على التعليقات. يستهدف numpy الثعابين الأقدم (3.5 التعليقات التوضيحية المقدمة ، IIRC) وهذا من شأنه كسر تلك البنيات ، لذلك ربما تنظر في كتابة ملفات .pyi أو تحقق من مستندات mypy لمعرفة ما إذا كان هناك المزيد من الإرشادات حول أفضل الممارسات.

لقد قمنا بعمل التعليقات التوضيحية حتى الآن في الأجزاء الأساسية المنفصلة
المستودع ، لكنها كانت عملية بطيئة.

في الخميس 14 نوفمبر 2019 الساعة 9:57 صباحًا كتب بن صموئيل [email protected] :

أوصي بعمل القليل وفتح العلاقات العامة للحصول على التعليقات. حبيبي
يستهدف الثعابين الأقدم (3.5 شروح مقدمة ، IIRC) وهذا
قد يكسر تلك البنيات ، لذلك ربما تنظر في كتابة ملفات .pyi أو تحقق منها
مستندات mypy لمعرفة ما إذا كان هناك المزيد من الإرشادات حول أفضل الممارسات.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/numpy/numpy/issues/7370؟email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFVREXG43VMVB40
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

تتطلب @ bsamuel-ui numpy حاليًا Python 3.5+ ، وتنص NEP-29 [1] على أنه يجب رفعها إلى 3.6+
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

التعليقات التوضيحية (للوظائف وأنواع الإرجاع) مدعومة بالفعل في جميع إصدارات Python 3 ؛ 3.6 قدم فقط التعليقات التوضيحية المتغيرة. في إصدار Python 3 المبكر (<3.5) ، يجب عليك استخدام منفذ خلفي للوحدة typing .

لقد أضفت طلب سحب مع ملف .pyi الأول الخاص بي. إنها تحتاج إلى بعض العمل ولكن سيكون من الرائع أن تقوموا بإلقاء نظرة عليها حتى أتمكن من الحصول على بعض الملاحظات الأولية

كما هو مذكور في gh-14905 ، لدينا بدايات مكتبة stub في https://github.com/numpy/numpy-stubs. سيكون من الرائع إجراء ذلك مع الاختبارات المناسبة ومن ثم يمكننا تحديد أفضل طريقة لحزمها أو دمجها في عدد صحيح.

mattip سيئة بلدي. سأزيل طلب السحب من numpy وأضيف طلبًا جديدًا إلى numpy-stubs

لا يزال مفتوحًا ، لكنني أعتقد أن numpy يدعم ذلك بالفعل في الإصدار الرئيسي

مرحبا،
أحاول تعريف اسم مستعار من النوع aa لـ vector 3d ، لذا فإن مصفوفة عددية من الشكل (3 ،) من dtype int32.

(أعلم أنه يمكنني كتابة تلميح باستخدام np.ndarray ولكن كيف يمكنني الحصول على مزيد من التحديد؟ لقد قرأت هنا جميعًا ولم أحصل عليه ، كما أنني أبحث عن برنامج تعليمي حول كيفية استخدام الأنواع المعقدة للكتابة في بايثون اوجد اي شيء. )

كما يمكن أن تكتب:

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

حاولت أن أفعل:

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

هل هي الطريقة الصحيحة للقيام بذلك؟

هل يمكن لأي شخص هنا أن يوجهني إلى برنامج تعليمي أو مثال من فضلك؟

أيضًا ، وجدت هذا الريبو وهو "تلميحات الكتابة لـ Numpy": https://github.com/ramonhagenaars/nptyping

هل سيدمج Numpy هذا؟
تضمين التغريدة

mattip

كما هو مذكور في gh-14905 ، لدينا بدايات مكتبة stub في https://github.com/numpy/numpy-stubs.

يبدو أنه تم دمج هذا في الريبو الرئيسي. هل تم إصدار هذا أم أنه موجود على خريطة الطريق؟ محاولة تحديد ما إذا كان يجب علينا استكشاف شيء طرف ثالث مثل https://github.com/ramonhagenaars/nptyping أو (بشكل مثالي) انتظار / استخدام تلميحات الكتابة المدعومة رسميًا.

شكر.

لقد دمجنا الكثير من numyp-stubs في فرع التطوير. يمكنك متابعة التقدم بالبحث عن تسمية الكتابة الثابتة . نأمل أن يكون هذا جزءًا من الإصدار التالي. يمكنك تجربة ما تم دمجه حاليًا باستخدام إصدار HEAD من numpy. نحن نبحث دائمًا عن مساهمين: المراجعة البناءة والتوثيق والتعليقات على القضايا وطلبات السحب هي بعض الطرق للمساعدة.

(أعلم أنه يمكنني كتابة تلميح باستخدام np.ndarray ولكن كيف يمكنني الحصول على مزيد من التحديد؟ لقد قرأت هنا جميعًا ولم أحصل عليه ، كما أنني أبحث عن برنامج تعليمي حول كيفية استخدام الأنواع المعقدة للكتابة في بايثون اوجد اي شيء. )

هناك الكثير من الاهتمام بهذا المجال ، ولكن الكتابة الأكثر تحديدًا (الأنواع والأبعاد) لمصفوفات NumPy غير مدعومة حتى الآن.

@ GilShoshan94 FWIW لقد قدمت https://github.com/ramonhagenaars/nptyping/issues/27

أيضًا FWIW ، إليك ما يستخدمه pybind11 للتوقيعات من نوع "التعليق التوضيحي" في سلاسل __doc__ للأحمال الزائدة:
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