પાયથોન પ્રકાર તપાસનાર સરખામણી: ખાલી કન્ટેનર અનુમાન

ખાલી કન્ટેનર શા માટે પાયથોન પ્રકારના ચેકર્સને તોડે છે — અને તમે તેના વિશે શું કરી શકો છો

2015 માં PEP 484 એ ટાઇપ સંકેતો રજૂ કર્યા ત્યારથી પાયથોનની ક્રમિક ટાઇપિંગ સિસ્ટમ નોંધપાત્ર રીતે પરિપક્વ બની છે. આજે, લાખો વિકાસકર્તાઓ પ્રોડક્શનમાં આવે તે પહેલાં બગ્સ પકડવા માટે સ્ટેટિક ટાઇપ ચેકર્સ પર આધાર રાખે છે. પરંતુ ટાઇપ સિસ્ટમનો એક સૂક્ષ્મ, નિરાશાજનક ખૂણો છે જે હજી પણ અનુભવી ઇજનેરોને પણ ટ્રિપ કરે છે: ખાલી કન્ટેનરમાં કયા પ્રકારનું હોય છે? જ્યારે તમે ટીકા વિના x = [] લખો છો, ત્યારે તમારા પ્રકાર તપાસનારને અનુમાન લગાવવું પડશે — અને જુદા જુદા ચેકર્સ અલગ રીતે અનુમાન લગાવશે. આ વિચલન મોટા કોડબેઝની જાળવણી કરતી ટીમો માટે વાસ્તવિક સમસ્યાઓનું સર્જન કરે છે, જ્યાં સ્વિચિંગ અથવા ટાઇપ ચેકર્સને જોડવાથી રાતોરાત સેંકડો અણધારી ભૂલો સપાટી પર આવી શકે છે.

આ લેખ ચાર મુખ્ય પાયથોન પ્રકારના ચેકર્સ - mypy, pyright, pytype અને pyre — ખાલી કન્ટેનર અનુમાનને કેવી રીતે હેન્ડલ કરે છે, તેઓ શા માટે અસંમત છે, અને તમારી ટૂલિંગ પસંદગીને ધ્યાનમાં લીધા વિના તમે ટાઇપ-સેફ પાયથોન લખવા માટે કઈ વ્યવહારિક વ્યૂહરચના અપનાવી શકો છો તેનું વર્ણન કરે છે.

મુખ્ય સમસ્યા: ખાલી કન્ટેનર સ્વાભાવિક રીતે અસ્પષ્ટ છે

પાયથોનની આ નિર્દોષ લાઇનને ધ્યાનમાં લો: પરિણામો = []. શું પરિણામો એ સૂચિ[int] છે? એક સૂચિ[str]? સૂચિ[str, Any]]? વધારાના સંદર્ભ વિના, ખરેખર જાણવાની કોઈ રીત નથી. પાયથોન રનટાઈમ પર ધ્યાન આપતું નથી — યાદીઓ કુદરત દ્વારા વિજાતીય છે — પરંતુ સ્ટેટિક ટાઈપ ચેકર્સને તેમનું કામ કરવા માટે દરેક વેરીએબલને ચોક્કસ પ્રકાર સોંપવાની જરૂર છે. આ પાયથોનની ગતિશીલ સુગમતા અને સ્થિર વિશ્લેષણ પ્રદાન કરવાનો પ્રયાસ કરે છે તેવી બાંયધરી વચ્ચે મૂળભૂત તણાવ પેદા કરે છે.

સમસ્યા શબ્દકોશો અને સમૂહો સાથે સંયોજન કરે છે. ખાલી {} વાસ્તવમાં ડિક્ટ તરીકે પદચ્છેદ કરવામાં આવે છે, સેટ નહીં, જે પ્રકાર-સ્તરની અસ્પષ્ટતાની ટોચ પર સિન્ટેક્ટિક અસ્પષ્ટતા ઉમેરે છે. અને નેસ્ટેડ કન્ટેનર — ડિફૉલ્ટડિક્ટ(સૂચિ) અથવા પરિણામો = {k: [] કીમાં k માટે વિચારો — અનુમાન એન્જિનોને તેમની મર્યાદામાં દબાણ કરો. દરેક પ્રકારના તપાસકર્તાએ તેની પોતાની હ્યુરિસ્ટિક્સ વિકસાવી છે, અને મોટાભાગના વિકાસકર્તાઓને ખ્યાલ આવે છે તેના કરતાં તફાવતો વધુ નોંધપાત્ર છે.

ઉત્પાદન પ્રણાલીઓમાં વાસ્તવિક વર્કલોડ પર પ્રક્રિયા કરવામાં આવે છે - પછી ભલે તે ગ્રાહકના રેકોર્ડને હેન્ડલ કરતી CRM હોય, ઇન્વોઇસિંગ મોડ્યુલ લાઇન આઇટમ્સ જનરેટ કરતી હોય, અથવા એનાલિટિક્સ પાઇપલાઇન એકંદર મેટ્રિક્સ હોય - ખાલી કન્ટેનર શરૂઆતના દાખલાઓ તરીકે સતત દેખાય છે. તેમના પ્રકારોને ખોટા મેળવવાથી માત્ર લિંટર ચેતવણીઓ જ પેદા થતી નથી; તે અસલી ભૂલોને ઢાંકી શકે છે જે રનટાઈમમાં સરકી જાય છે.

Mypy: ગર્ભિત કોઈપણ સાથે વિલંબિત અનુમાન

Mypy, સૌથી જૂનું અને સૌથી વધુ વ્યાપક રીતે અપનાવવામાં આવેલ પાયથોન પ્રકાર તપાસનાર, ખાલી કન્ટેનર માટે પ્રમાણમાં હળવા અભિગમ અપનાવે છે. જ્યારે તે ફંક્શન સ્કોપ પર x = [] નો સામનો કરે છે, ત્યારે તે પ્રકારના નિર્ણયને મુલતવી રાખવા અને અનુગામી વપરાશમાંથી તત્વ પ્રકારનું અનુમાન કરવાનો પ્રયાસ કરે છે. જો તમે x.append(42) પછી x = [] લખો, તો mypy list[int]નું અનુમાન કરશે. આ "જોડાઓ" વ્યૂહરચના આશ્ચર્યજનક રીતે સરળ એવા કેસ માટે સારી રીતે કામ કરે છે જ્યાં કન્ટેનર સમાન અવકાશમાં ભરાયેલું હોય.

જો કે, સંદર્ભ અને કડક સેટિંગ્સના આધારે mypy નું વર્તન નાટકીય રીતે બદલાય છે. મોડ્યુલ સ્કોપ (ટોચ-લેવલ કોડ) પર, અથવા જ્યારે કન્ટેનરને વસાવવામાં આવે તે પહેલાં અન્ય ફંક્શનમાં પસાર કરવામાં આવે છે, ત્યારે mypy વારંવાર સૂચિ[Any] પર આવે છે. --કડક ધ્વજ હેઠળ, આ એક ભૂલને ટ્રિગર કરે છે, પરંતુ ડિફોલ્ટ મોડમાં તે ચૂપચાપ પસાર થાય છે. આનો અર્થ એ છે કે કડક મોડ વિના mypy ચલાવતી ટીમો ડઝનેક અસ્પષ્ટ-ટાઈપ કરેલા કન્ટેનર એકઠા કરી શકે છે જે તેના હેતુને હરાવીને ટાઈપ સિસ્ટમમાંથી એસ્કેપ હેચ તરીકે કામ કરે છે.

એક ખાસ કરીને સૂક્ષ્મ વર્તણૂક: 0.990 પહેલાના mypy સંસ્કરણો કેટલીકવાર આંતરિક રીતે સૂચિ[અજ્ઞાત]નું અનુમાન કરે છે અને પછી સોંપણી પર સૂચિ[કોઈ] સુધી વિસ્તૃત થાય છે. 0.990 પછી, અનુમાનને કડક કરવામાં આવ્યું હતું, પરંતુ પરિવર્તને વાસ્તવિક-વિશ્વના કોડબેઝની આશ્ચર્યજનક સંખ્યાને તોડી નાખી હતી જે તેને સમજ્યા વિના અનુમતિપૂર્ણ વર્તન પર આધાર રાખતા હતા. આ એક પુનરાવર્તિત થીમ છે — ખાલી કન્ટેનર અનુમાનમાં ફેરફાર એ સૌથી વધુ વિક્ષેપજનક પ્રકારના ચેકર અપડેટ્સમાંનો એક છે કારણ કે પેટર્ન ખૂબ સર્વવ્યાપક છે.

પાયરાઇટ: કડક અનુમાન અને "અજ્ઞાત" પ્રકાર

માઈક્રોસોફ્ટ દ્વારા વિકસાવવામાં આવેલ અને વી.એસ. કોડમાં પાયલેન્સને પાવર આપતી પાયરાઈટ, મૂળભૂત રીતે અલગ ફિલોસોફિકલ વલણ ધરાવે છે. શાંતિપૂર્વક કોઈપણ પર પાછા આવવાને બદલે, પાયરાઈટ અજ્ઞાત (એક પ્રકાર કે જે હજી સુધી નિર્ધારિત કરવામાં આવ્યો નથી) અને કોઈપણ (ટાઈપ ચેકિંગમાંથી સ્પષ્ટ નાપસંદ) વચ્ચે તફાવત કરે છે. જ્યારે તમે પાયરાઇટના કડક મોડમાં x = [] લખો છો, ત્યારે તે સૂચિ[અજ્ઞાત]નું અનુમાન કરે છે અને ડાયગ્નોસ્ટિકની જાણ કરે છે, જે તમને ટીકા પ્રદાન કરવાની ફરજ પાડે છે.

પાયરાઇટ ક્ષેત્રમાં સંકુચિત વિશે પણ વધુ આક્રમક છે. જો તમે લખો છો:

• x = [] ત્યારબાદ x.append("hello") — pyright infers list[str]
• x = [] ત્યારબાદ x.append(1) પછી x.append("hello") — pyright infers list[int | str]
• x = [] સીધા જ સૂચિ[int] ની અપેક્ષા રાખતા ફંક્શનમાં પસાર થાય છે — કૉલ-સાઇટ સંદર્ભમાંથી pyright infers list[int]
• x = [] રીટર્ન ટાઈપ એનોટેશન વિના ફંક્શનમાંથી પરત આવે છે — પાઈરાઈટ અનુમાન લગાવવાને બદલે ભૂલની જાણ કરે છે

આ દ્વિપક્ષીય અનુમાન (કોલ સાઇટ્સમાંથી અનુગામી ઉપયોગ અને અપેક્ષિત પ્રકારો બંનેનો ઉપયોગ કરીને) ખાલી કન્ટેનર માટે mypy કરતાં પાયરાઇટ નોંધપાત્ર રીતે વધુ ચોક્કસ બનાવે છે. ટ્રેડઓફ વર્બોસિટી છે: કેટલાક ઓપન-સોર્સ સ્થળાંતર અહેવાલોના વિશ્લેષણ અનુસાર, mypyના કડક મોડની તુલનામાં સામાન્ય બિન-એનોટેટેડ કોડબેઝ પર પાયરાઇટનો કડક મોડ લગભગ 30-40% વધુ સમસ્યાઓ ફ્લેગ કરે છે. જટિલ બેકએન્ડ સિસ્ટમ્સ બનાવતી ટીમો માટે — કહો કે, CRM, પગારપત્રક અને એનાલિટિક્સ પર ફેલાયેલા 207 ઇન્ટરકનેક્ટેડ મોડ્યુલ્સનું સંચાલન કરતું પ્લેટફોર્મ — pyright ની કડકતા સૂક્ષ્મ ઇન્ટરફેસ મિસમેચને પકડે છે જે ઉદાર અનુમાન ચૂકી જશે.

Pytype and Pyre: The Less Traveled Roads

ગૂગલનો પાઈટાઈપ કદાચ સૌથી વધુ વ્યવહારુ અભિગમ અપનાવે છે. એનોટેશનની આવશ્યકતા અથવા કોઈપણ પર પાછા આવવાને બદલે, pytype કાર્ય સીમાઓ પર કન્ટેનરનો ઉપયોગ કેવી રીતે થાય છે તે ટ્રૅક કરવા માટે સંપૂર્ણ-પ્રોગ્રામ વિશ્લેષણનો ઉપયોગ કરે છે. જો તમે એક ફંક્શનમાં ખાલી સૂચિ બનાવો છો અને તેને બીજામાં પાસ કરો છો જેમાં પૂર્ણાંકો જોડાય છે, તો pytype ઘણીવાર કોઈપણ ટીકાઓ વિના list[int] અનુમાન કરી શકે છે. આ ક્રોસ-ફંક્શન અનુમાન કોમ્પ્યુટેશનલી ખર્ચાળ છે — મોટા કોડબેઝ પર માયપી અથવા પાયરાઈટ કરતાં pytype નોંધપાત્ર રીતે ધીમું છે — પરંતુ તે બિન-અનુકૃત કોડ પર ઓછા ખોટા હકારાત્મક પેદા કરે છે.

Pytype ખાલી કન્ટેનર માટે "આંશિક પ્રકારો"નો ખ્યાલ પણ રજૂ કરે છે. તાજી બનાવેલ []ને આંશિક પ્રકાર મળે છે જે ક્રમશઃ રિફાઇન થાય છે કારણ કે ચેકર વધુ ઉપયોગનો સામનો કરે છે. આ કલ્પનાત્મક રીતે ભવ્ય છે પરંતુ જ્યારે આંશિક પ્રકારનું સંપૂર્ણ નિરાકરણ ન કરી શકાતું હોય ત્યારે ગૂંચવણભર્યા ભૂલ સંદેશાઓ પેદા કરી શકે છે, જેમ કે જ્યારે ખાલી કન્ટેનર ક્યારેય વસ્યા વિના અનેક કાર્યોમાંથી પસાર થાય છે.

મેટાની ચિત્તા, તે દરમિયાન, માયપીની વર્તણૂકની નજીક છે પરંતુ વધુ કડક ડિફોલ્ટ સાથે. Pyre x = [] ને સૂચિ[અજ્ઞાત] તરીકે માને છે અને મોટાભાગના સંદર્ભોમાં ટીકાની જરૂર છે. જ્યાં pyre પોતાની જાતને અલગ પાડે છે તે ક્વાર્ગ્સ તરીકે ઉપયોગમાં લેવાતા ખાલી ડિક્શનરી લિટલ્સના સંચાલનમાં છે - વેબ ફ્રેમવર્કમાં એક સામાન્ય પેટર્ન. Pyre પાસે કીવર્ડ દલીલ સંદર્ભોમાંથી શબ્દકોશના પ્રકારોનું અનુમાન કરવા માટે ખાસ-કેસ લોજિક છે, જે ફ્રેમવર્ક-હેવી કોડબેસેસમાં ટીકાનો ભાર ઘટાડે છે. આપેલ છે કે મોટા ભાગની આધુનિક વેબ એપ્લીકેશનોમાં રૂપરેખાંકન અને વિનંતી હેન્ડલિંગ માટે શબ્દકોશ અનપેકીંગનો ભારે ઉપયોગ સામેલ છે, આ વ્યવહારિકતા ડિવિડન્ડ ચૂકવે છે.

રીઅલ-વર્લ્ડ ઇમ્પેક્ટ: જ્યારે ઇન્ફરન્સ ડાયવર્જન્સ કરડે છે

જ્યાં સુધી તમે પ્રોડક્શન કોડબેઝમાં તેનો અનુભવ ન કરો ત્યાં સુધી ટાઇપ ચેકર્સ વચ્ચેના તફાવતો શૈક્ષણિક લાગશે. વ્યાપાર એપ્લિકેશન્સમાં એક સામાન્ય પેટર્નનો વિચાર કરો: ડેટા સ્ટ્રક્ચર શરૂ કરવું જે શરતી રીતે રચાય છે.

સૌથી વધુ ખતરનાક ખાલી કન્ટેનર ચેકર્સ ફ્લેગના પ્રકાર નથી — તે એવા છે જે ચૂપચાપ અનુમાનિત કોઈપણ પ્રકાર સાથે પસાર થાય છે, જ્યાં સુધી ડાઉનસ્ટ્રીમ ફંક્શન TypeError સાથે રનટાઈમ પર ક્રેશ ન થાય ત્યાં સુધી અસંગત ડેટાને ચેતવણી વિના એકઠા કરવાની મંજૂરી આપે છે જે લગભગ અસંભવિત છે.

એક નક્કર ઉદાહરણ: ફિનટેક સ્ટાર્ટઅપ પરની એક ટીમે ઉત્પાદન સમસ્યાને ડીબગ કરવામાં ત્રણ દિવસ ખર્ચ કર્યાની જાણ કરી, જ્યાં પેમેન્ટ પ્રોસેસિંગ ફંક્શનમાં આરંભ કરાયેલ ખાલી સૂચિને mypy દ્વારા સૂચિ[કોઈ] તરીકે અનુમાનિત કરવામાં આવી હતી. સૂચિમાં ચલણની રકમ માટે દશાંશ ઑબ્જેક્ટ્સ હોવાના હતા, પરંતુ તેના બદલે કોડ પાથ ફ્લોટ મૂલ્યો ઉમેરી રહ્યો હતો. માયપીના ઉદાર અનુમાનએ તેને શાંતિથી મંજૂરી આપી. ફ્લોટ અંકગણિતમાં ગોળાકાર ભૂલોને કારણે 12,000 ઇન્વૉઇસના બેચ પર $0.01ની વિસંગતતા આવી ત્યારે જ બગ સામે આવ્યો. જો તેઓએ કડક મોડમાં પાયરાઈટનો ઉપયોગ કર્યો હોત, અથવા ખાલી સૂચિને સૂચિ[દશાંશ] તરીકે ટીકા કરી હોત, તો બગ વિકાસ સમયે પકડાઈ ગયો હોત.

મેવેઝમાં, જ્યાં પ્લેટફોર્મ 138,000+ વપરાશકર્તા ખાતાઓમાં ઇન્વોઇસિંગ, પેરોલ ગણતરીઓ અને નાણાકીય વિશ્લેષણની પ્રક્રિયા કરે છે, આ પ્રકારનો પ્રકાર-સુરક્ષા તફાવત સૈદ્ધાંતિક નથી — તે યોગ્ય પેરોલ રન અને મોંઘા પુનઃગણતરી વચ્ચેનો તફાવત છે. કન્ટેનર આરંભની આસપાસ સખત ટાઇપિંગ શિસ્ત એ "કંટાળાજનક" એન્જિનિયરિંગ પ્રથાઓમાંની એક છે જે ઉત્તેજક ઉત્પાદન ઘટનાઓને અટકાવે છે.

રક્ષણાત્મક કન્ટેનર આરંભ માટે શ્રેષ્ઠ વ્યવહારો

તમારી ટીમ કયા પ્રકારના ચેકરનો ઉપયોગ કરે છે તે ધ્યાનમાં લીધા વિના, ખાલી કન્ટેનરની અસ્પષ્ટતાને સંપૂર્ણપણે દૂર કરવા માટે નક્કર વ્યૂહરચના છે. ધ્યેય એ છે કે ખાલી કન્ટેનર માટે ક્યારેય અનુમાન પર આધાર રાખવો નહીં — પ્રકારને સ્પષ્ટ બનાવો જેથી તમારો કોડ તમામ ચેકર્સ પર પોર્ટેબલ હોય અને સંસ્કરણો વચ્ચે અનુમાન વર્તણૂકમાં ફેરફારથી પ્રતિરક્ષા હોય.

1. હંમેશા ખાલી કન્ટેનર વેરીએબલ્સની ટીકા કરો. પરિણામો = [] ને બદલે પરિણામો: list[int] = [] લખો. ડીબગીંગ સમયની સરખામણીમાં નાની વર્બોસીટી કિંમત નજીવી છે. આ એક પ્રેક્ટિસ લગભગ 80% ખાલી કન્ટેનર અનુમાન સમસ્યાઓને દૂર કરે છે.
2. જટિલ કન્ટેનર માટે ફેક્ટરી ફંક્શનનો ઉપયોગ કરો. cache = {} ને બદલે, def make_cache() -> dict[str, list[UserRecord]]: return {} જેવું ફંક્શન લખો. રીટર્ન ટાઇપ એનોટેશન ઇચ્છિત પ્રકારને અસ્પષ્ટ અને સ્વ-દસ્તાવેજીકૃત બનાવે છે.
3. બિન-તુચ્છ પ્રકારો માટે શાબ્દિક કરતાં ટાઇપ કરેલ કન્સ્ટ્રક્ટરને પ્રાધાન્ય આપો. સેટ કોમ્પ્રીહેન્સન ઇન્ફરન્સ પર આધાર રાખવાને બદલે આઇટમ્સ: સેટ[int] = સેટ() લખો. ડિફૉલ્ટડિક્ટ અને કાઉન્ટર માટે, હંમેશા પ્રકાર પેરામીટર પ્રદાન કરો: કાઉન્ટ્સ: કાઉન્ટર[str] = કાઉન્ટર().
4. નવા કોડ માટે તમારા પ્રકાર તપાસનારના કડક મોડને ગોઠવો. mypy અને pyright બંને પ્રતિ-ફાઇલ અથવા પ્રતિ-ડિરેક્ટરી ગોઠવણીને સમર્થન આપે છે. લેગસી કોડને ધીમે ધીમે સ્થાનાંતરિત કરતી વખતે નવા મોડ્યુલ્સ પર કડક તપાસને સક્ષમ કરો. આ નવા ગર્ભિત-ટાઈપ કરેલા કન્ટેનરના સંચયને અટકાવે છે.
5. તમારી CI પાઇપલાઇનની સરખામણીમાં પ્રકાર તપાસનાર ઉમેરો. તમારા કોડબેઝ પર mypy અને pyright બંનેને ચલાવવાથી અનુમાન અલગતા વહેલા પકડે છે. જો પેટર્ન એક તપાસનારને પાસ કરે છે પરંતુ બીજામાં નિષ્ફળ જાય છે, તો તે સંકેત છે કે પ્રકાર પૂરતો સ્પષ્ટ નથી.

ધ બીગર પિક્ચર: ટીમ પ્રેક્ટિસ તરીકે તપાસવાનું ટાઇપ કરો

ખાલી કન્ટેનર અનુમાન એ આખરે પાયથોનની ટાઈપ સિસ્ટમમાં એક મોટા પડકારનું સૂક્ષ્મ સ્વરૂપ છે: સગવડતા અને સલામતી વચ્ચેનો તણાવ. પાયથોનની ફિલસૂફી "અમે બધા પુખ્ત વયના લોકો સાથે સંમતિ આપીએ છીએ" પ્રોટોટાઇપિંગ અને સ્ક્રિપ્ટ્સ માટે સુંદર રીતે કામ કરે છે, પરંતુ હજારો વપરાશકર્તાઓને સેવા આપતી પ્રોડક્શન સિસ્ટમ્સને મજબૂત ગેરંટીની જરૂર છે. હકીકત એ છે કે ચાર મુખ્ય પ્રકારનાં તપાસકર્તાઓ [] ના પ્રકાર જેવી મૂળભૂત બાબત પર અસંમત છે તે અન્ડરસ્કોર કરે છે કે પાયથોન ટાઇપિંગ ઇકોસિસ્ટમ હજુ પણ પરિપક્વ છે.

જટીલ પ્લેટફોર્મ બનાવતી એન્જિનિયરિંગ ટીમો માટે — ભલે તમે મુઠ્ઠીભર માઇક્રોસર્વિસિસનું સંચાલન કરી રહ્યાં હોવ અથવા Mewayzના બિઝનેસ OS જેવા સેંકડો ઇન્ટરકનેક્ટેડ મોડ્યુલો સાથે સંકલિત સિસ્ટમનું સંચાલન કરો — વ્યવહારુ સલાહ સીધી છે: ખાલી કન્ટેનર માટે અનુમાન પર આધાર રાખશો નહીં, એક પ્રકાર તપાસનાર પસંદ કરો અને તેને કડક રીતે ગોઠવો અને દસ્તાવેજના પ્રકારને રૂપરેખાંકિત કરો. મશીન દ્વારા ચકાસી શકાય તેવું. જ્યારે તમારો કોડબેઝ સ્કેલ થાય છે ત્યારે [] ને બદલે સૂચિ[ઇન્વૉઇસ] લખવામાં વિતાવેલી પાંચ મિનિટ તમને ડિબગિંગના કલાકો બચાવશે.

જેમ કે PEP 696 (ડિફૉલ્ટ પ્રકાર પરિમાણો) અને PEP 695 (ટાઈપ પેરામીટર સિન્ટેક્સ) નવી પાયથોન આવૃત્તિઓમાં ઉતરવાનું ચાલુ રાખે છે, સ્પષ્ટ ટાઇપિંગના અર્ગનોમિક્સમાં સુધારો થતો રહેશે. "એનોટેટેડ" અને "અનોટેટેડ" પાયથોન વચ્ચેનું અંતર ઓછું થશે. પરંતુ તે દિવસ સુધી, સ્પષ્ટ કન્ટેનર પ્રકારો પાયથોન ડેવલપરની ટૂલકીટમાં સૌથી વધુ-આરઓઆઈ પ્રથાઓમાંની એક રહી છે - એક નાની શિસ્ત કે જે દરેક મોડ્યુલ, દરેક સ્પ્રિન્ટ અને દરેક પ્રોડક્શન ડિપ્લોયમેન્ટમાં ચક્રવૃદ્ધિ વ્યાજ ચૂકવે છે.