Numpy: Ndarray, dtype और ufunc के लिए hinting / annotation (PEP 484) टाइप करें

मुझे नहीं लगता कि किसी ने भी इसके बारे में सोचा है। शायद आप करना चाहेंगे? :-)

मैं यह भी सुझाव देने जा रहा हूं कि यदि आप इस बात का अनुसरण करना चाहते हैं कि हम gh मुद्दे को बंद करें और चर्चा को मेलिंग सूची में ले जाएं, क्योंकि यह ओपन-एंडेड डिज़ाइन चर्चाओं के लिए बेहतर अनुकूल है।

एसओ पर यह जवाब मिलने के बाद, मैंने इस मुद्दे को बंद करने का फैसला किया है।

स्पष्ट होने के लिए, हमें वास्तव में शांत नए अजगर सुविधाओं या कुछ भी (बल्कि विपरीत) का समर्थन करने में कोई आपत्ति नहीं है; यह सिर्फ इतना है कि हम कई संसाधनों के बिना एक स्वयंसेवक रन प्रोजेक्ट कर रहे हैं, इसलिए सामान केवल तभी होता है जब कोई दिलचस्पी रखने वाला व्यक्ति इसे करने के लिए कदम उठाता है।

मेलिंग सूची आमतौर पर सबसे अच्छी जगह होती है यदि आप किसी चीज़ पर काम शुरू करने की कोशिश कर रहे हों या कुछ अन्य इच्छुक लोगों की भर्ती में मदद करने की उम्मीद कर रहे हों।

धन्यवाद, @njsmith मैंने अधिक व्यवस्थित मुद्दा-ट्रैकिंग के कारण यहां शुरू करने का फैसला किया, जैसा कि एक असंरचित मेलिंग सूची के विपरीत (मैं अन्य विशेषताओं के बीच 'फ़ीचर अनुरोध' टैग की तलाश में था ...)

चूंकि एसओ ने मुझे जवाब दिया था, इसलिए मुझे एक व्यवहार्य समाधान के साथ वापस मिल गया, मैंने इस मामले को छोड़ने का फैसला किया।
हो सकता है कि उसके जवाब को शामिल करने के लिए 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

सीसी @mrocklin

यह वास्तव में NumPy के लिए एक बढ़िया अतिरिक्त होगा। टाइप किए गए या NumPy को आगे बढ़ाने के लिए अगले कदम क्या होंगे? यहां तक ​​कि एक अपूर्ण स्टब उपयोगी होगा और मैं थोड़ी सी दिशा के साथ मदद करने के लिए खुश हूं?

@henryJack शुरू करने के लिए सबसे अच्छी जगह शायद टूलींग होगी: यह पता लगाना कि हम मूल प्रकार के एनोटेशन को न्यूपी रिपॉजिटरी में कैसे एकीकृत कर सकते हैं (और आदर्श रूप से उनका परीक्षण करते हैं) एक तरह से मैपी के साथ काम करता है और उन्हें लगातार जोड़ने का समर्थन करता है।

फिर, अत्यंत न्यूनतम एनोटेशन के साथ शुरू करें और हम वहां से जा सकते हैं। विशेष रूप से, मैं अभी के लिए dtype एनोटेशन को छोड़ दूंगा क्योंकि हमारे पास उन्हें निर्दिष्ट करने का एक अच्छा तरीका नहीं है (यानी, केवल ndarray , ndarray[int] )।

यदि यह उपयोगी है, तो मेरे पास एनोटेशन का एक वैकल्पिक संस्करण है जो मैंने Google पर उपयोग के लिए लिखा है और स्रोत खोल सकता है। लेकिन हमारे पास अपनी अनूठी निर्माण प्रणाली है और पाइप्टाइप के साथ संभवतया यह अपस्ट्रीम को अपस्ट्रीम में पोर्ट करता हुआ होगा।

मुझे लगता है कि एनोटेशन का परीक्षण करने का एकमात्र तरीका वास्तव में नमूना कोड स्निपेट पर माइपी को चलाने और आउटपुट की जांच करना है?

क्या एनोटेशन को कोड के साथ या अलग स्टब्स के रूप में एकीकृत करना बेहतर होगा?

मुझे लगता है कि हमें ड्रॉपबॉक्स और पांडा से भी सीखना चाहिए कि हमें कोडबेस बनाम कोर डेटा संरचनाओं की पत्तियों से शुरू करना चाहिए?

@shoyer figure out how we can integrate basic type annotations
बस नहीं करना होगा https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi in numpy मॉड्यूल बेस डायरेक्टरी बिल्कुल वैसा ही करते हैं .. किसी तरह के प्रायोगिक संस्करण में। कम से कम

क्या एनोटेशन को कोड के साथ या अलग स्टब्स के रूप में एकीकृत करना बेहतर होगा?

कोड के साथ एकीकृत सुंदर होगा, लेकिन मुझे नहीं लगता कि यह अभी तक NumPy के लिए संभव है। टाइप एनोटेशन के टिप्पणी स्ट्रिंग संस्करण के साथ भी, हमें पायथन 2 पर typing से आयात करने की आवश्यकता होगी, और NumPy पर निर्भरता जोड़ना तालिका से बहुत अधिक है।

इसके अलावा, अधिकांश मुख्य डेटा संरचनाएं और कार्य (चीजें जैसे ndarray और array ) को विस्तार मॉड्यूल में परिभाषित किया गया है, हमें वैसे भी स्टब्स का उपयोग करने की आवश्यकता होगी।

केवल खगोलीय मॉड्यूल बेस डायरेक्टरी में https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.py डाल नहीं सकते हैं। बिल्कुल वैसा ही .. किसी न किसी तरह के प्रायोगिक संस्करण में। कम से कम

हां, मुझे लगता है कि यह बाहरी कोड के लिए पर्याप्त होगा। लेकिन अपूर्ण प्रकार के एनोटेशन वाले पुस्तकालयों को mypy कैसे संभालता है?

यदि संभव हो तो, हम केवल शीर्ष स्तर पर बजाय numpy.core.multiarray सीधे एनोटेट कर सकते हैं। ( multiarray एक्सटेंशन मॉड्यूल है, जहां NumPy के मुख्य प्रकार ndarray परिभाषित किए गए हैं।) मुझे लगता है कि यह NumPy को अपने कुछ प्योर-पायथन मॉड्यूल के कुछ प्रकारों की जाँच करने की अनुमति देगा।

मैं उत्सुक हूँ, 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 के साथ है? क्या यह उनके आयाम या आकार के साथ पैरामीरिज़ के लिए भी संभव है? पायथन टाइपिंग मॉड्यूल कितना परिष्कार करता है?

हाँ, वे अपने dtype द्वारा मानकीकृत हैं। मैं टाइपिंग मॉड्यूल का कोई विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि आपके पास Generic[dtype, int] को मानकीकृत करने के लिए ndim । मेरा मानना ​​है कि जूलिया यही करती है। मुझे यकीन नहीं है कि अगर आप आसानी से आकार को माप सकते हैं। न ही मुझे यकीन है कि जो लाभ लाएगा या पहली जगह में ऐसा क्यों नहीं किया गया।

क्या कोई dtype पैरामीटर में numpy dtypes का उपयोग कर सकता है या यह केवल टाइपिंग हो सकता है
मॉड्यूल प्रकार?

यह भी अजीब है कि numpy.empty किसी भी प्रकार की एक सरणी देता है। मुझे संदेह है
यह dtype = कीवर्ड मान से प्रकार को अंतर करने और लेने के लिए चुनौतीपूर्ण है?

1 सितंबर, 2017 को 6:42 बजे, "जैक्स केवम" नोटिफिकेशन @github.com ने लिखा:

हाँ, वे अपने dtype द्वारा मानकीकृत हैं। मैं टाइपिंग का कोई विशेषज्ञ नहीं हूँ
मॉड्यूल, लेकिन मुझे लगता है कि आपके पास केवल सामान्य प्रकार का जेनेरिक प्रकार हो सकता है [dtype,
int] ndim पर परिमाणित करने के लिए। मेरा मानना ​​है कि जूलिया यही करती है। मैं नहीं
यकीन है कि अगर आप आसानी से आकार पर पैरामीटर बना सकते हैं। और न ही मुझे यकीन है कि क्या
लाभ जो लाएगा या ऐसा क्यों नहीं किया गया था कि पहली जगह में क्यों।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 , या म्यूट
सूत्र
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
।

आप सुन्न dtypes का उपयोग कर सकते हैं, हमें बस उन्हें परिभाषित करने की आवश्यकता है। यहाँ 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 -L113333

हमें आयामों को शामिल करते हुए हस्ताक्षर भी करने होंगे। उदाहरण के लिए, np.expand_dims नक्शे ndim -> ndim+1 ।

मुझे लगता है कि प्रत्येक गैर-नकारात्मक पूर्णांक के लिए कक्षाओं को परिभाषित करने के लिए काम करने वाला एक दृष्टिकोण है, जैसे, Zero , One , Two , Three , ।। । और फिर प्रत्येक के लिए अधिभार परिभाषित करते हैं। वह बहुत जल्दी थक जाता।

TensorFlow में, tf.Dimension() और tf.TensorShape() आपको वैचारिक रूप से अभिव्यक्त होने देते हैं। लेकिन यह ऐसा कुछ नहीं है जो टाइप सिस्टम में किया जाता है। बल्कि, प्रत्येक फ़ंक्शन के साथ एक सहायक जुड़ा होता है जो आउटपुट के स्थिर आकार को इनपुट के आकार और किसी भी गैर-दसियों तर्क से निर्धारित करता है। मुझे लगता है कि अगर हमें NumPy के साथ ऐसा करने की उम्मीद है, तो हमें कुछ इसी तरह की आवश्यकता होगी, लेकिन पायथन टाइपिंग सिस्टम में ऐसा कुछ भी नहीं है जो बताता है कि इस प्रकार का लचीलापन है।

@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 जैसे dtypes का परीक्षण कर सकता था। मुझे तयशुदा तर्क को हटाना था, यह पता नहीं लगा सका कि उसे कैसे काम करना है।

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 स्केलर प्रकारों पर जोर देते हैं, उदाहरण के लिए, np.ndarray[np.integer] बजाय np.ndarray[int] ।

यह वास्तव में मैंने सोचा की तुलना में थोड़ा आसान है क्योंकि TypeVar का bound तर्क है। तो मेरे उदाहरण को संशोधित:

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

मुझे तयशुदा तर्क को हटाना था, यह पता नहीं लगा सका कि उसे कैसे काम करना है।

मुझे पूरा यकीन नहीं है कि आप यहाँ क्या कर रहे थे?

मैंने सिर्फ स्टब में dtype के डिफ़ॉल्ट मान को एनकोड करने की कोशिश की। उन्होंने मायपी-डेटा रेपो में ऐसा किया।

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

आपके उदाहरण के बाद, मैं dtype के लिए डिफ़ॉल्ट तर्क के साथ काम करने के लिए mypy प्राप्त करने में सक्षम नहीं था। मैंने dtype: Type[D]=float और dtype: Type[D]=Type[float] ।

मुझे लगता है कि dtype भी जेनेरिक प्रकार बनने की आवश्यकता है, और फिर आपको डिफ़ॉल्ट मूल्य को float , उदा जैसे np.float64 जैसे एक सामान्य सामान्य उपवर्ग में सेट करने की आवश्यकता है, उदा।

# 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 के मुद्दे पर कुछ संबंधित चर्चा की गई है ट्रैकर (अजगर / mypy # 3540 ज्यादातर)। वहाँ, हम मुख्य मुद्दे को समझते हैं कि सुन्न सरणियों को उनके प्रकार में उनके आयामों को शामिल किया जाता है, और वर्तमान प्रकार प्रणाली वास्तव में इसका समर्थन नहीं करती है। यदि मैपी या टाइप किए गए प्रोजेक्ट्स किसी भी तरह से सुन्न के लिए काम करने में मदद कर सकते हैं, तो कृपया हमें बताएं!

Mypy के मुद्दे पर कुछ संबंधित चर्चा की गई है ट्रैकर (अजगर / mypy # 3540 ज्यादातर)। वहाँ, हम मुख्य मुद्दे को समझते हैं कि सुन्न सरणियों को उनके प्रकार में उनके आयामों को शामिल किया जाता है, और वर्तमान प्रकार प्रणाली वास्तव में इसका समर्थन नहीं करती है। यदि मैपी या टाइप किए गए प्रोजेक्ट्स किसी भी तरह से सुन्न के लिए काम करने में मदद कर सकते हैं, तो कृपया हमें बताएं!

मैं पैरामीट्रिज्ड प्रकारों में अधिक या कम जानकारी एन्कोडिंग की कल्पना कर सकता हूं। उदाहरण के लिए एक सरणी जैसे 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 जैसे उपकरणों को संभालने में सक्षम होगा? हम कितना परिष्कृत हो सकते हैं?

यह बहुत स्पष्ट लगता है कि आकार और आयामीता का समर्थन करने के लिए प्रकार प्रणाली में महत्वपूर्ण काम की आवश्यकता होगी। मैं इसका स्वागत करता हूं (और बस अजगर / मैपी # 3540 में विचारों का एक गुच्छा नीचे लिखा है), लेकिन अब के लिए हम NumPy के लिए उस दायरे से बाहर कहते हैं। बस ndarray[float64] काम करना काफी कठिन लगता है, जिसे संख्यात्मक प्रकार की पदानुक्रम और सामान्य प्रकार की चुनौतियाँ दी गई हैं।

हां, मुझे लगता है कि पहला कदम उन प्रकारों पर विचार आकार और अन्य अतिरिक्त बाधाओं को ध्यान में रखते हुए बिना खतना (और पंडों और स्केलेर) के लिए बुनियादी टाइपिंग समर्थन प्राप्त करने के लिए होगा।

अन्य अतिरिक्त बाधाओं के साथ मुद्दा यह है कि यह केवल एक dtype (आकार = 5,6) का वर्णन करने के लिए पर्याप्त नहीं है, लेकिन उस आकृति पर एक बाधा का वर्णन करने के लिए एक भाषा होनी चाहिए। आप कल्पना कर सकते हैं कि आप एक ऐसे फंक्शन को परिभाषित करना चाहते हैं जो इनपुट के रूप में केवल वर्गाकार आकृतियों को स्वीकार करता है, या जहां एक आयाम को दूसरे में 2x होना है।

अनुबंध परियोजना में ऐसा कुछ किया गया था।

मुझे यह भी लगता है कि PEP 472 यहां समर्थन करने के लिए बहुत अच्छा होगा, क्योंकि तब कोई वास्तव में Array[float64, ndim=2] जैसी चीजें कर सकता था।

वास्तव में, PEP 472 टाइपिंग के लिए अच्छा होगा, हालाँकि यह संभवत: ऐसा करने के लिए आसान सुधारों में से एक होगा! (कृपया मुझे पिंग करें यदि आप इसके चारों ओर चर्चा को फिर से शुरू करने में रुचि रखते हैं, जैसा कि मुझे लगता है कि अनुक्रमण में नाम के लिए सम्मोहक उपयोग के मामले भी हैं।)

मुझे यकीन नहीं है कि मैं कैसे योगदान देता हूं, लेकिन मुझे निश्चित रूप से लगता है कि यह कई कारणों से एक भयानक विशेषता होगी। लेकिन, हम उस दिशा में जा रहे हैं, तो ऐसा लगता है कि [] सिर्फ एक वस्तु को कॉल करने का एक अलग तरीका बन जाता है। तो object(*args, **kwargs) कुछ करता है, object[*args, **kwargs] कुछ और, और फिर हम सामान्य भी कर सकते हैं और object{*args, **kwags} और object<*args, **kwargs> । ;-)

@ हमतार : इसे दूसरे तरीके से देखते हुए, शायद हमें 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 टाइप करने की अनुमति देने के लिए पर्याप्त होगा। अधिक विवरण और उदाहरण के लिए डॉक्टर देखें।

यदि हम पहले से ही NDArray और ndarray अलग रखने का विकल्प चुन रहे हैं, तो dtypes और आकृतियों दोनों को सपोर्ट करने का एक संभावित समाधान:

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 ( dtype='float32' ) के साथ प्रकार का अनुमान नहीं लगा सकते। शायद अधिक समस्यात्मक रूप से, यह पायथन प्रकारों से dtype=float जैसे प्रकार के अनुमानों को भी नहीं संभालता है। लेकिन ये प्रकार अस्पष्ट हो सकते हैं (जैसे, dtype=int नक्शे np.int64 Linux पर और np.int32 Windows पर), इसलिए संभवतः स्पष्ट सामान्य प्रकार के वैसे भी उपयोग करना बेहतर है। यह ठीक है यदि प्रकार का अनुमान हर संभव मामले में काम नहीं करता है, जब तक कि विनिर्देश dtype=float Any त्रुटि के बजाय अनुमानित नहीं हैं।

लेकिन ये प्रकार अस्पष्ट हो सकते हैं (उदाहरण के लिए, dtype = int मैप्स पर np.int64 लिनक्स पर और np.int32 विंडोज पर)

यह अस्पष्ट नहीं है - सभी मामलों में, यह np.int_ लिए मैप करता है, जो कि C long ।

मैंने एक अलग पैकेज में NumPy के लिए टाइप-स्टब्स लिखने पर आम सहमति प्राप्त करने के लिए मेलिंग सूची लिखी है:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

अद्भुत, धन्यवाद @shoyer !

मेलिंग सूची पर सहमति के अनुसार, मैं व्यापार के लिए https://github.com/numpy/numpy_stubs खोलने की घोषणा करना चाहता हूं!

हम बुनियादी एनोटेशन (कोई dtype समर्थन) के साथ शुरू करेंगे। यदि कोई रेपो के लिए पीईपी 561 मचान जोड़ने के लिए एक मूल पीआर को एक साथ रखना चाहता है जिसे सराहना की जाएगी!

हाँ, हाँ, 1000X हाँ!

इस समस्या के बाद किसी के लिए भी समस्याएँ: मैंने अजगर / टाइपिंग ट्रैकर पर दो मुद्दे खोले हैं:

• ndarray टाइपिंग सामान्य तौर पर (https://github.com/python/typing/issues/513)
• ndarray टाइपिंग के लिए वाक्यविन्यास (https://github.com/python/typing/issues/516)

टाइपिंग सुविधा के लिए अपेक्षित रिलीज़ समय क्या है?
क्या 2.7 संगतता बनाए रखने का प्रयास करने का कोई कारण है?
एक प्रारंभिक टिप्पणी ने अजगर 2 के साथ एकीकरण में कठिनाई का उल्लेख किया। तब से, ऐसा लगता है कि सुन्न ने अपना रुख बदल दिया है।

चीजें लक्ष्य की ओर बढ़ रही हैं, मुझे पता है, लेकिन क्या पायथन 3.4-3.6 जैसी किसी चीज को लक्षित करना समझ में आएगा?

टाइपिंग सुविधा के लिए अपेक्षित रिलीज़ समय क्या है?

पाइकॉन में इस (पूर्णांक जेनेरिक उर्फ ​​सरल आश्रित प्रकार) के बारे में कई चर्चाएं हुईं, मैं इन चर्चाओं पर आधारित एक प्रोटो-पीईपी लिखूंगा और मूल डॉक जो @shoyer द्वारा लिखित है। मेरा लक्ष्य PEP लिखा जाना है, जिसे मैयप में लागू किया गया है और इसे Python 3.8 Beta 1 के लिए समय में स्वीकार किया गया है (पायथन 2 के लिए typing में नए प्रकारों का बाद का बैकपोर्ट अत्यधिक संभावना है)

खुद के लिए एनोटेशन लिखने के लिए https://github.com/numpy/numpy-stubs। आपको उन स्टब्स को चालू स्थिति में (माइपी के नवीनतम संस्करण के साथ) स्थापित और उपयोग करने में सक्षम होना चाहिए, लेकिन वे पूर्ण से बहुत दूर हैं। मदद की सराहना की जाएगी!

निश्चित रूप से, मैं जहां मैं कर सकता हूं, वहां मदद करने के लिए खुश हूं और मैंने भंडार देखा। मुझे सिर्फ इतना पता है कि इन चीजों में समय लगता है।
मैंने रेपो को देखा और 2.7 संगतता का उल्लेख करते हुए एक प्रतिबद्ध देखा, यही कारण है कि मैंने पूछा।

पायथन 3.8 बीटा रिलीज का समय 2019 के मध्य है । नेम्पी ने उल्लेख किया कि वे 2018 के अंत में नई सुविधाओं को रोक देंगे।

टंकण एक "अच्छा-टू-है" सुविधा के रूप में सुन्न के लिए एक "होना चाहिए" के विपरीत लगता है। जैसे, दो भाषाओं को लक्षित करना थोड़ा कठिन लगता है, विशेष रूप से, यदि फीचर सुप्पी की अपनी समर्थन समय सीमा से परे अच्छी तरह से दिखाई देने लगेगा।

मुझे यह पढ़ने में दिलचस्पी होगी कि पीईपी में @ilevkivskyi का क्या कहना है।

@hmarrfk आप पायथन 2.7 समर्थन के बारे में एक अच्छी बात उठाते हैं। सच कहूं, तो मैंने इसे पूरी तरह से अभी तक नहीं सोचा है। मुझे उम्मीद है कि हम अंततः इसे छोड़ देंगे, लेकिन शायद इससे पहले नहीं कि मैपी ही पायथन 2.7 समर्थन को छोड़ दें, यह देखते हुए कि टाइपिंग के लिए एक प्रमुख उपयोग-केस पायथन 2/3 संगत कोड लिख रहा है।

अभी के लिए, हमारे टाइप एनोटेशन में अजगर 2 का समर्थन करने के लिए कई समझौतों की आवश्यकता नहीं है, इसलिए मैं इसे छोड़ने में खुश हूं, विशेष रूप से यह देखते हुए कि यह एक योगदानकर्ता से आया है जो स्पष्ट रूप से इसमें रुचि रखते थे।

मैं यह देखने के लिए फिर से प्रहार करना चाहता था कि क्या चर्चा आगे बढ़ी है, विशेष रूप से टाइपिंग आकार की जानकारी के बारे में, जो कि मेरे बहुत सारे अनुप्रयोगों में विशेष रूप से उपयोगी होगी। क्या कोई स्टेटस ट्रैकर है या यह कोई उच्च प्राथमिकता नहीं है कि कोई संसाधन इसके प्रति समर्पित हो?

transonic , खस्ता त्वरक को सामान्य करने के लिए एक परियोजना है, हमारे पास पायथन एनोटेशन के विकल्प के रूप में एक प्रकार का संकेत वाक्यविन्यास है https://transonic.readthedocs.io/en/latest/examples/type_hin.html.html

यदि यह इस समस्या के लिए उपयोगी है, तो मैं उल्लेख करूँगा कि मैंने डॉकस्ट्रिंग को टिप्पणी टाइप करने के लिए एक उपकरण बनाया है: https://pypi.org/project/doc484/

मैं कई टिप्पणियों में सिंक के प्रकार रखने के लिए कई परियोजनाओं में पूर्व-प्रतिबद्ध के साथ इसका उपयोग करता हूं।

आपको अभी भी PEP484 अनुरूप होने के लिए अपने docstrings के प्रकारों को परिवर्तित करना होगा।

सभी को नमस्कार,

मैं अपना हिस्सा करना चाहता था इसलिए मैंने रेपो को छोड़ दिया और टाइप संकेत जोड़ना शुरू कर दिया। मेरा विचार नीचे-ऊपर काम करना था, इसलिए "सरल" कार्यों के साथ शुरू करें और वहां से ऊपर की तरफ काम करें। (कम लटकने वाले फलों से शुरू)

उदाहरण के लिए _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 पुराने pythons (3.5 पेश किए गए एनोटेशन, IIRC) को लक्षित कर रहा है और यह उन बिल्ड्स को तोड़ देगा, इसलिए हो सकता है कि .pyi फ़ाइलों को देखें या यह देखने के लिए mypy डॉक्स देखें कि क्या सर्वोत्तम प्रथाओं पर थोड़ा और मार्गदर्शन है।

हम अलग-अलग सुन्न-स्टब्स में अब तक एनोटेशन कर रहे हैं
भंडार, लेकिन यह एक धीमी प्रक्रिया रही है।

Thu, Nov 14, 2019 को सुबह 9:57 बजे बेन सैमुअल नोटिफिकेशन @ithub.com ने लिखा:

मैं सुझाव देने के लिए थोड़ा सा और एक पीआर करने की सलाह दूंगा। Numpy
पुराने अजगर (3.5 पेश किए गए एनोटेशन, IIRC) और यह लक्ष्य कर रहा है
उन बिल्ड को तोड़ देगा, इसलिए शायद .pyi फ़ाइलों या जाँच को देखें
यह देखने के लिए कि क्या सर्वोत्तम प्रथाओं पर थोड़ा और मार्गदर्शन है या नहीं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVHHCLCLPPJKWJQQ73RTVTV4A5A5CNFSM4B436CI2YY3PNVWKH5252HFH5252&hl=hf&hl=hi
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
।

@ bsamuel-ui numpy को फिलहाल पायथन 3.5+ की आवश्यकता है, और NEP-29 [1] में कहा गया है कि इसे 3.6+ पर टक्कर देना ठीक होना चाहिए
[१] https://numpy.org/neps/nep-0029-deprecation_policy.html

एनोटेशन (फ़ंक्शन आर्ग्स और रिटर्न प्रकार के लिए) वास्तव में सभी पायथन 3 संस्करणों में समर्थित हैं; 3.6 केवल चर एनोटेशन की शुरुआत की। प्रारंभिक पायथन 3 संस्करण (<3.5) में आपको typing मॉड्यूल के बैकपोर्ट का उपयोग करना होगा।

मैंने अपनी पहली .pyi फ़ाइल के साथ एक पुल अनुरोध जोड़ा है। इसे कुछ काम करने की ज़रूरत है लेकिन यह अच्छा होगा यदि आप लोग इस पर एक नज़र डाल सकते हैं ताकि मुझे कुछ प्रारंभिक प्रतिक्रिया मिल सके

जैसा कि gh-14905 में उल्लेख किया गया है, हमारे पास https://github.com/numpy/numpy-stubs में एक स्टब लाइब्रेरी की शुरुआत है

मेरी बुर @ मट्टीप मैं सुन्न से पुल अनुरोध को हटा दूंगा और सुन्न-स्टब्स में एक नया जोड़ दूंगा

यह अभी भी खोला गया है, लेकिन मुझे विश्वास है कि सुन्न पहले से ही मास्टर संस्करण में समर्थन करता है

नमस्ते,
मैं वेक्टर 3 डी के लिए एए टाइप उर्फ ​​को परिभाषित करने की कोशिश कर रहा हूं, इसलिए dtype int32 की आकृति (3) का एक संख्यात्मक सरणी।

(मुझे पता है कि मैं np.ndarray के साथ संकेत टाइप कर सकता हूं, लेकिन मैं और अधिक विशिष्ट कैसे प्राप्त कर सकता हूं? मैंने यहां सब पढ़ा है और यह नहीं मिला है, मैं एक ट्यूटोरियल भी खोजता हूं कि पायथन में टाइप करने के लिए संख्यात्मक प्रकार कैसे उपयोग करें लेकिन नहीं कुछ भी पता लगाएँ। )

जैसे लिखना संभव है:

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

मैंने करने की कोशिश की:

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

क्या यह करने का सही तरीका है?

क्या कोई व्यक्ति मुझे एक ट्यूटोरियल या उदाहरण के रूप में बता सकता है?

इसके अलावा, मुझे यह रेपो मिला जो "Numpy के लिए टाइप संकेत" है: https://github.com/ramonhagenaars/tptyping

क्या नम्पी इसे एकीकृत करेगी?
@ramonhagenaars

@mattip

जैसा कि gh-14905 में उल्लेख किया गया है, हमारे पास https://github.com/numpy/numpy-stubs में एक स्टब लाइब्रेरी की शुरुआत है

ऐसा लगता है कि इसे मुख्य रेपो में मिला दिया गया है। क्या यह जारी किया गया है, या यह रोडमैप पर है? यह तय करने की कोशिश की जा रही है कि क्या हमें किसी तीसरे पक्ष का पता लगाना चाहिए जैसे https://github.com/ramonhagenaars/nptyping या (आदर्श रूप से) आधिकारिक तौर पर समर्थित प्रकार के संकेतों के लिए प्रतीक्षा करें / उपयोग करें।

धन्यवाद।

हमने बहुत से स्तूप-स्टब्स को विकास शाखा में विलय कर दिया है। आप स्थैतिक टाइपिंग लेबल की तलाश कर प्रगति का अनुसरण कर सकते हैं। उम्मीद है कि यह अगली रिलीज का हिस्सा होगा। आप कोशिश कर सकते हैं कि वर्तमान में सुन्न के एक हेड संस्करण का उपयोग करके क्या विलय किया गया है। हम हमेशा योगदानकर्ताओं की तलाश करते हैं: रचनात्मक समीक्षा, प्रलेखन, और मुद्दों पर टिप्पणियां और पुल अनुरोध मदद करने के कुछ तरीके हैं।

(मुझे पता है कि मैं np.ndarray के साथ संकेत टाइप कर सकता हूं, लेकिन मैं और अधिक विशिष्ट कैसे प्राप्त कर सकता हूं? मैंने यहां सब पढ़ा है और यह नहीं मिला है, मैं एक ट्यूटोरियल भी खोजता हूं कि पायथन में टाइप करने के लिए संख्यात्मक प्रकार कैसे उपयोग करें लेकिन नहीं कुछ भी पता लगाएँ। )

इस क्षेत्र में बहुत रुचि है, लेकिन NumPy सरणियों के लिए अधिक विशिष्ट टाइपिंग (dtypes और आयाम) अभी तक समर्थित नहीं हैं।

@ GilShoshan94 FWIW मैंने https://github.com/ramonhagenaars/nptyping/issues/27 दायर की है

इसके अलावा एफडब्ल्यूआईडब्ल्यू, यहां __doc__ ओवरलोड के लिए pybind11 "
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/include/pybind11/higen/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