मुझे लगता है कि हम धीरे-धीरे इस तथ्य के अभ्यस्त हो रहे हैं कि पायथन में एनोटेशन हैं: उन्हें कार्यों और विधियों ( पीईपी 484 ) के एनोटेशन में दो रिलीज (3.5) वापस लाया गया था, और अंतिम रिलीज (3.6) में चर ( पीईपी 526 ) के लिए।

चूंकि ये दोनों PEP MyPy से प्रेरित थे, इसलिए मैं आपको बताऊंगा कि इस स्थिर विश्लेषक का उपयोग करने के दौरान सांसारिक खुशियाँ और संज्ञानात्मक असंगतियाँ मुझे किस तरह का इंतजार करवाती हैं , साथ ही साथ टाइपिंग सिस्टम भी।

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

जेनरिक (टाइपिंग। जेनरिक)

एनोटेशन में List[int] , Callable[[int, str], None] List[int] जैसे कुछ का उपयोग करना अच्छा है।
यह बहुत अच्छा है जब विश्लेषक निम्नलिखित कोड पर प्रकाश डालता है:

 T = ty.TypeVar('T') class A(ty.Generic[T]): value: T A[int]().value = 'str' # error: Incompatible types in assignment # (expression has type "str", variable has type "int") 

हालाँकि, क्या होगा यदि हम एक पुस्तकालय लिखते हैं, और इसका उपयोग करने वाले प्रोग्रामर एक स्थिर विश्लेषक का उपयोग नहीं करेंगे?
उपयोगकर्ता को एक मूल्य के साथ वर्ग को शुरू करने के लिए मजबूर करना, और फिर उसके प्रकार को स्टोर करना है?

 T = ty.TypeVar('T') class Gen(Generic[T]): value: T ref: Type[T] def __init__(self, value: T) -> None: self.value = value self.ref = type(value) 

किसी तरह उपयोगकर्ता के अनुकूल नहीं है।
लेकिन अगर आप ऐसा करना चाहते हैं तो क्या होगा?

 b = Gen[A](B()) 

इस प्रश्न के उत्तर की तलाश में, मैं थोड़ा typing , और कारखानों की दुनिया में डूब गया।

तथ्य यह है कि जेनेरिक वर्ग के उदाहरण को शुरू करने के बाद, इसे __origin_class__ विशेषता __origin_class__ है, जिसमें __args__ विशेषता होती है, जो एक प्रकार का टपल है। हालाँकि, __new__ से, साथ ही __new__ , इस तक __new__ नहीं है। इसके अलावा यह __call__ में नहीं है। और चाल यह है कि Generic के उपवर्ग के आरंभ के समय Generic यह एक अन्य _GenericAlias में बदल जाता है, जो अंतिम प्रकार सेट करता है, या तो ऑब्जेक्ट के आरम्भ होने के बाद, उसके __getithem__ सभी तरीकों सहित, या जब __getithem__ पर __getithem__ किया __getithem__ है। इस प्रकार, ऑब्जेक्ट का निर्माण करते समय जेनेरिक प्रकार प्राप्त करने का कोई तरीका नहीं है।

 def _init_obj_ref(obj: 'Gen[T]') -> None: """Set object ref attribute if not one to initialized arg.""" if not hasattr(obj, 'ref'): obj.ref = obj.__orig_class__.__args__[0] # type: ignore class ValueHandler(Generic[T]): """Handle object _value attribute, asserting it's type.""" def __get__(self, obj: 'Gen[T]', cls: Type['Gen[T]'] ) -> Union[T, 'ValueHandler[T]']: if not obj: return self _init_obj_ref(obj) if not obj._value: obj._value = obj.ref() return obj._value def __set__(self, obj: 'Gen[T]', val: T) -> None: _init_obj_ref(obj) if not isinstance(val, obj.ref): raise TypeError(f'has to be of type {obj.ref}, pasted {val}') obj._value = val class Gen(Generic[T]): _value: T ref: Type[T] value = ValueHandler[T]() def __init__(self, value: T) -> None: self._value = value class A: pass class B(A): pass b = Gen[A](B()) b.value = A() b.value = int() # TypeError: has to be of type <class '__main__.A'>, pasted 0 

[UPD]: सुबह मैंने typing मॉड्यूल में ही करने की कोशिश करने का फैसला किया, लेकिन सरल:

 import typing as ty T = ty.TypeVar('T') class A(ty.Generic[T]): # __args are unique every instantiation __args: ty.Optional[ty.Tuple[ty.Type[T]]] = None value: T def __init__(self, value: ty.Optional[T]=None) -> None: """Get actual type of generic and initizalize it's value.""" cls = ty.cast(A, self.__class__) if cls.__args: self.ref = cls.__args[0] else: self.ref = type(value) if value: self.value = value else: self.value = self.ref() cls.__args = None def __class_getitem__(cls, *args: ty.Union[ty.Type[int], ty.Type[str]] ) -> ty.Type['A']: """Recive type args, if passed any before initialization.""" cls.__args = ty.cast(ty.Tuple[ty.Type[T]], args) return super().__class_getitem__(*args, **kwargs) # type: ignore a = A[int]() b = A(int()) c = A[str]() print([a.value, b.value, c.value]) # [0, 0, ''] 

[UPD]: typing डेवलपर इवान लेविंस्की ने कहा कि दोनों विकल्प अप्रत्याशित रूप से टूट सकते हैं।

वैसे भी, आप जो भी उपयोग कर सकते हैं। शायद __class_getitem__ थोड़ा बेहतर है, कम से कम __class_getitem__ एक प्रलेखित विशेष विधि है (हालांकि जेनरिक के लिए इसका व्यवहार नहीं है)।

कार्य और उपनाम

हां, जेनरिक बिल्कुल आसान नहीं है:
उदाहरण के लिए, यदि हम कहीं एक फ़ंक्शन को एक तर्क के रूप में स्वीकार करते हैं, तो इसका एनोटेशन स्वचालित रूप से सहसंयोजक से विपरीत हो जाता है:

 class A: pass class B(A): pass def foo(arg: 'A') -> None: #   A  B ... def bar(f: Callable[['A'], None]): #       A ... 

और सिद्धांत रूप में, मुझे तर्क के बारे में कोई शिकायत नहीं है, केवल इसे सामान्य उपनामों के माध्यम से हल किया जाना है:

 TA = TypeVar('TA', bound='A') def foo(arg: 'B') -> None: #   B   ... def bar(f: Callable[['TA'], None]): #     A  B ... 

सामान्य तौर पर, प्रकार की परिवर्तनशीलता पर अनुभाग को ध्यान से पढ़ा जाना चाहिए, और एक से अधिक बार।

पिछड़ी अनुकूलता

यह इतना गर्म नहीं है: संस्करण से 3.7 Generic ABCMeta का एक उपवर्ग है, जो बहुत सुविधाजनक और अच्छा है। यह खराब है कि यह कोड को तोड़ता है यदि यह 3.6 पर चल रहा है।

संरचनात्मक वंशानुक्रम (Stuctural Suptyping)

सबसे पहले मैं बहुत खुश था: इंटरफेस वितरित किए गए थे! इंटरफेस की भूमिका typing_extensions मॉड्यूल से Protocol वर्ग द्वारा की typing_extensions है, जो @runtime डेकोरेटर के साथ संयोजन में, आपको यह जांचने की अनुमति देता है कि क्या वर्ग सीधे इनहेरिटेंस के बिना इंटरफ़ेस को लागू करता है या नहीं। MyPy को एक गहरे स्तर पर भी हाइलाइट किया गया है।

हालाँकि, मैंने कई उत्तराधिकारियों की तुलना में रनटाइम में ज्यादा व्यावहारिक लाभ नहीं देखा।
ऐसा लगता है कि डेकोरेटर केवल आवश्यक नाम के साथ विधि की उपस्थिति के लिए जांच करता है, यहां तक ​​कि तर्कों की संख्या की जांच किए बिना, अनुपालन का उल्लेख नहीं करने के लिए:

 import typing as ty import typing_extensions as te @te.runtime class IntStackP(te.Protocol): _list: ty.List[int] def push(self, val: int) -> None: ... class IntStack: def __init__(self) -> None: self._list: ty.List[int] = list() def push(self, val: int) -> None: if not isinstance(val, int): raise TypeError('wrong pushued val type') self._list.append(val) class StrStack: def __init__(self) -> None: self._list: ty.List[str] = list() def push(self, val: str, weather: ty.Any=None) -> None: if not isinstance(val, str): raise TypeError('wrong pushued val type') self._list.append(val) def push_func(stack: IntStackP, value: int): if not isinstance(stack, IntStackP): raise TypeError('is not IntStackP') stack.push(value) a = IntStack() b = StrStack() c: ty.List[int] = list() push_func(a, 1) push_func(b, 1) # TypeError: wrong pushued val type push_func(c, 1) # TypeError: is not IntStackP 

दूसरी ओर, MyPy, बदले में, अधिक चालाकी से व्यवहार करता है, और प्रकारों की असंगति को उजागर करता है:

 push_func(a, 1) push_func(b, 1) # Argument 1 to "push_func" has incompatible type "StrStack"; # expected "IntStackP" # Following member(s) of "StrStack" have conflicts: # _list: expected "List[int]", got "List[str]" # Expected: # def push(self, val: int) -> None # Got: # def push(self, val: str, weather: Optional[Any] = ...) -> None 

संचालक अधिभार

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

 class A: def __add__(self, other) -> int: return 3 def __iadd__(self, other) -> 'A': if isinstance(other, int): return NotImplemented return A() var = A() var += 3 # Inferred type is 'A', but runtime type is 'int'? 

यदि मिश्रित असाइनमेंट विधि NotImplemented , तो Python पहले __radd__ खोज करता है, फिर __add__ , और voila का उपयोग करता है।

फॉर्म के किसी भी उपवर्ग तरीकों को ओवरलोड करने के लिए भी यही लागू होता है:

 class A: def __add__(self, x : 'A') -> 'A': ... class B(A): @overload def __add__(self, x : 'A') -> 'A': ... @overload def __add__(self, x : 'B') -> 'B' : ... 

कुछ स्थानों पर, चेतावनियाँ पहले ही प्रलेखन में स्थानांतरित हो गई हैं, कुछ स्थानों पर वे अभी भी ठेस पर काम करते हैं। लेकिन योगदानकर्ताओं का सामान्य निष्कर्ष ऐसे ओवरलोड को स्वीकार्य छोड़ देना है।