Python કોડની 4 મિલિયન લીટીઓ ટાઇપચેક કરવાનો માર્ગ. ભાગ 2

આજે અમે ડ્રૉપબૉક્સે પાયથોન કોડની લાખો લાઈનો માટે ટાઈપ કંટ્રોલનું આયોજન કેવી રીતે કર્યું તે વિશેની સામગ્રીના અનુવાદનો બીજો ભાગ પ્રકાશિત કરી રહ્યાં છીએ.

→ ભાગ એક વાંચો

સત્તાવાર પ્રકાર આધાર (PEP 484)

અમે હેક વીક 2014 દરમિયાન ડ્રૉપબૉક્સમાં mypy સાથે અમારા પ્રથમ ગંભીર પ્રયોગો કર્યા. હેક વીક એ ડ્રૉપબૉક્સ દ્વારા હોસ્ટ કરવામાં આવતી એક-અઠવાડિયાની ઇવેન્ટ છે. આ સમય દરમિયાન, કર્મચારીઓ તેઓ જે ઇચ્છે છે તેના પર કામ કરી શકે છે! ડ્રૉપબૉક્સના કેટલાક સૌથી પ્રસિદ્ધ ટેક્નૉલૉજી પ્રોજેક્ટ આના જેવી ઇવેન્ટ્સમાં શરૂ થયા હતા. આ પ્રયોગના પરિણામે, અમે નિષ્કર્ષ પર આવ્યા કે mypy આશાસ્પદ લાગે છે, જો કે પ્રોજેક્ટ હજી વ્યાપક ઉપયોગ માટે તૈયાર નથી.

તે સમયે, પાયથોન પ્રકારની સંકેત પ્રણાલીઓને માનક બનાવવાનો વિચાર હવામાં હતો. મેં કહ્યું તેમ, પાયથોન 3.0 થી ફંક્શન્સ માટે ટાઇપ એનોટેશનનો ઉપયોગ કરવો શક્ય હતું, પરંતુ આ ફક્ત મનસ્વી અભિવ્યક્તિઓ હતા, વ્યાખ્યાયિત વાક્યરચના અને સિમેન્ટિક્સ વિના. પ્રોગ્રામ એક્ઝેક્યુશન દરમિયાન, આ ટીકાઓ, મોટાભાગે, ખાલી અવગણવામાં આવી હતી. હેક વીક પછી, અમે સિમેન્ટિક્સને માનક બનાવવા પર કામ કરવાનું શરૂ કર્યું. આ કાર્ય ઉદભવ તરફ દોરી ગયું PEP 484 (ગુઇડો વાન રોસમ, લ્યુકાઝ લંગા અને મેં આ દસ્તાવેજ પર સહયોગ કર્યો છે).

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

પ્રકાર સંકેત વાક્યરચના જે આખરે અપનાવવામાં આવી હતી તે તે સમયે mypy દ્વારા સમર્થન આપવામાં આવ્યું હતું તેના જેવું જ હતું. PEP 484 3.5 માં Python 2015 સાથે રજૂ કરવામાં આવ્યું હતું. પાયથોન હવે ગતિશીલ રીતે ટાઇપ કરેલી ભાષા ન હતી. હું આ ઘટનાને પાયથોન ઇતિહાસમાં એક મહત્વપૂર્ણ સીમાચિહ્નરૂપ તરીકે વિચારવાનું પસંદ કરું છું.

સ્થળાંતરની શરૂઆત

2015 ના અંતમાં, ડ્રૉપબૉક્સે mypy પર કામ કરવા માટે ત્રણ લોકોની ટીમ બનાવી. તેમાં ગિડો વાન રોસમ, ગ્રેગ પ્રાઇસ અને ડેવિડ ફિશરનો સમાવેશ થાય છે. તે ક્ષણથી, પરિસ્થિતિ ખૂબ જ ઝડપથી વિકસિત થવા લાગી. માયપીના વિકાસમાં પ્રથમ અવરોધ કામગીરી હતી. મેં ઉપર સંકેત આપ્યા મુજબ, પ્રોજેક્ટના શરૂઆતના દિવસોમાં મેં mypy અમલીકરણને C માં ભાષાંતરિત કરવાનું વિચાર્યું હતું, પરંતુ આ વિચાર હમણાં માટે સૂચિમાંથી બહાર નીકળી ગયો હતો. અમે CPython દુભાષિયાનો ઉપયોગ કરીને સિસ્ટમ ચલાવવામાં અટવાયેલા હતા, જે mypy જેવા સાધનો માટે પૂરતું ઝડપી નથી. (PyPy પ્રોજેક્ટ, JIT કમ્પાઇલર સાથે વૈકલ્પિક પાયથોન અમલીકરણ, પણ અમને મદદ કરતું નથી.)

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

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

આ ડ્રૉપબૉક્સ પર પ્રકાર ચેકિંગના ઝડપી અને કુદરતી અપનાવવાનો સમયગાળો હતો. 2016 ના અંત સુધીમાં, અમારી પાસે પહેલેથી જ ટાઇપ એનોટેશન સાથે પાયથોન કોડની આશરે 420000 લાઇન હતી. ઘણા વપરાશકર્તાઓ ટાઇપ ચેકિંગ માટે ઉત્સાહી હતા. વધુ અને વધુ વિકાસ ટીમો ડ્રૉપબૉક્સ mypy નો ઉપયોગ કરી રહી હતી.

ત્યારે બધું સારું લાગતું હતું, પણ અમારે હજુ ઘણું કરવાનું હતું. અમે પ્રોજેક્ટના સમસ્યારૂપ વિસ્તારોને ઓળખવા અને કયા મુદ્દાઓને પહેલા ઉકેલવાની જરૂર છે તે સમજવા માટે સમયાંતરે આંતરિક વપરાશકર્તા સર્વેક્ષણો હાથ ધરવાનું શરૂ કર્યું (આ પ્રથા આજે પણ કંપનીમાં વપરાય છે). સૌથી મહત્વપૂર્ણ, જેમ તે સ્પષ્ટ થયું, બે કાર્યો હતા. પ્રથમ, અમને કોડના વધુ પ્રકારના કવરેજની જરૂર છે, બીજું, અમને ઝડપથી કામ કરવા માટે mypyની જરૂર છે. તે એકદમ સ્પષ્ટ હતું કે માયપીને ઝડપી બનાવવા અને તેને કંપનીના પ્રોજેક્ટ્સમાં અમલમાં મૂકવાનું અમારું કાર્ય હજી પૂર્ણ થયું નથી. અમે, આ બે કાર્યોના મહત્વથી સંપૂર્ણપણે વાકેફ છીએ, તેમને ઉકેલવા માટે તૈયાર છીએ.

વધુ ઉત્પાદકતા!

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

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

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

તેનાથી પણ વધુ ઉત્પાદકતા!

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

અમે mypy સંબંધિત અગાઉના વિચારોમાંથી એક પર પાછા ફરવાનું નક્કી કર્યું. એટલે કે, પાયથોન કોડને સી કોડમાં કન્વર્ટ કરવા. Cython (એક સિસ્ટમ કે જે તમને Python માં લખેલા કોડને C કોડમાં અનુવાદિત કરવાની મંજૂરી આપે છે) સાથે પ્રયોગ કરવાથી અમને કોઈ દૃશ્યમાન ગતિ મળી નથી, તેથી અમે અમારા પોતાના કમ્પાઈલરને લખવાના વિચારને પુનર્જીવિત કરવાનું નક્કી કર્યું. mypy કોડબેઝ (પાયથોનમાં લખાયેલ) પહેલાથી જ તમામ જરૂરી પ્રકારની ટીકાઓ ધરાવે છે, તેથી અમે વિચાર્યું કે સિસ્ટમને ઝડપી બનાવવા માટે આ ટીકાઓનો ઉપયોગ કરવાનો પ્રયાસ કરવો યોગ્ય રહેશે. મેં આ વિચારને ચકાસવા માટે ઝડપથી પ્રોટોટાઇપ બનાવ્યો. તે વિવિધ માઇક્રો-બેન્ચમાર્ક્સ પર પ્રદર્શનમાં 10 ગણો કરતાં વધુ વધારો દર્શાવે છે. અમારો વિચાર સીથોનનો ઉપયોગ કરીને પાયથોન મોડ્યુલોને C મોડ્યુલોમાં કમ્પાઇલ કરવાનો હતો અને ટાઇપ એનોટેશનને રન-ટાઇમ ટાઇપ ચેકમાં ફેરવવાનો હતો (સામાન્ય રીતે ટાઇપ એનોટેશનને રન-ટાઇમ પર અવગણવામાં આવે છે અને માત્ર ટાઇપ ચેકિંગ સિસ્ટમ્સ દ્વારા ઉપયોગમાં લેવાય છે). અમે વાસ્તવમાં પાયથોનમાંથી mypy અમલીકરણને એવી ભાષામાં અનુવાદિત કરવાની યોજના બનાવી છે કે જે સ્ટેટિકલી ટાઇપ કરવા માટે ડિઝાઇન કરવામાં આવી હતી, જે પાયથોન જેવી જ દેખાશે (અને, મોટાભાગે, કામ કરશે). (આ પ્રકારની ક્રોસ-લેંગ્વેજ માઈગ્રેશન એ mypy પ્રોજેક્ટની પરંપરા બની ગઈ છે. મૂળ mypy અમલીકરણ અલોરમાં લખવામાં આવ્યું હતું, ત્યારબાદ જાવા અને પાયથોનનું સિન્ટેક્ટિક હાઇબ્રિડ હતું).

CPython એક્સ્ટેંશન API પર ધ્યાન કેન્દ્રિત કરવું એ પ્રોજેક્ટ મેનેજમેન્ટ ક્ષમતાઓને ન ગુમાવવા માટેની ચાવી હતી. અમારે વર્ચ્યુઅલ મશીન અથવા mypy ને જરૂરી કોઈપણ લાઇબ્રેરીને અમલમાં મૂકવાની જરૂર નથી. વધુમાં, અમારી પાસે હજુ પણ સમગ્ર પાયથોન ઇકોસિસ્ટમ અને તમામ સાધનો (જેમ કે પાયટેસ્ટ)ની ઍક્સેસ હશે. આનો અર્થ એ થયો કે અમે વિકાસ દરમિયાન અર્થઘટન કરાયેલ પાયથોન કોડનો ઉપયોગ કરવાનું ચાલુ રાખી શકીએ છીએ, જે અમને કોડ કમ્પાઇલ થવાની રાહ જોવાને બદલે કોડ ફેરફારો અને તેનું પરીક્ષણ કરવાની ખૂબ જ ઝડપી પેટર્ન સાથે કામ કરવાનું ચાલુ રાખવા દે છે. એવું લાગતું હતું કે અમે બે ખુરશીઓ પર બેસીને એક સરસ કામ કરી રહ્યા છીએ, તેથી બોલવા માટે, અને અમને તે ગમ્યું.

કમ્પાઇલર, જેને આપણે mypyc કહીએ છીએ (કારણ કે તે પ્રકારોના વિશ્લેષણ માટે ફ્રન્ટ-એન્ડ તરીકે mypy નો ઉપયોગ કરે છે), તે ખૂબ જ સફળ પ્રોજેક્ટ હોવાનું બહાર આવ્યું છે. એકંદરે, અમે કેશીંગ વિના વારંવાર mypy રન માટે આશરે 4x ઝડપ હાંસલ કરી છે. mypyc પ્રોજેક્ટના મુખ્ય વિકાસમાં માઇકલ સુલિવાન, ઇવાન લેવકીવસ્કી, હ્યુ હેન અને મારી એક નાની ટીમ લગભગ 4 કેલેન્ડર મહિનાનો સમય લીધો. કામની આ રકમ mypy ને ફરીથી લખવા માટે જરૂરી હતી તેના કરતા ઘણી ઓછી હતી, ઉદાહરણ તરીકે, C++ અથવા Go માં. અને અમારે પ્રોજેક્ટમાં અન્ય ભાષામાં પુનઃલેખન કરતી વખતે જે ફેરફારો કરવા પડ્યા હોત તેના કરતા ઘણા ઓછા ફેરફારો કરવા પડ્યા હતા. અમે એવી પણ આશા રાખીએ છીએ કે અમે mypyc ને એવા સ્તર પર લાવી શકીએ કે અન્ય ડ્રૉપબૉક્સ પ્રોગ્રામરો તેનો ઉપયોગ તેમના કોડને કમ્પાઇલ કરવા અને તેને ઝડપી બનાવવા માટે કરી શકે.

પ્રદર્શનના આ સ્તરને હાંસલ કરવા માટે, અમારે કેટલાક રસપ્રદ એન્જિનિયરિંગ ઉકેલો લાગુ કરવા પડ્યા. આમ, કમ્પાઈલર ઝડપી, નીચા-સ્તરના C બાંધકામોનો ઉપયોગ કરીને ઘણી કામગીરીને ઝડપી બનાવી શકે છે.ઉદાહરણ તરીકે, સંકલિત ફંક્શન કૉલને C ફંક્શન કૉલમાં અનુવાદિત કરવામાં આવે છે. અને આવા કૉલ એક અર્થઘટન કાર્ય કૉલ કરતાં વધુ ઝડપી છે. કેટલાક ઑપરેશન્સ, જેમ કે ડિક્શનરી લુકઅપ, હજુ પણ CPython ના નિયમિત C-API કૉલ્સનો ઉપયોગ કરીને સામેલ છે, જે સંકલિત કરવામાં આવે ત્યારે માત્ર નજીવી રીતે ઝડપી હતા. અમે અર્થઘટન દ્વારા બનાવેલ સિસ્ટમ પરના વધારાના ભારને દૂર કરવામાં સક્ષમ હતા, પરંતુ આનાથી પ્રભાવની દ્રષ્ટિએ માત્ર એક નાનો ફાયદો થયો.

સૌથી સામાન્ય "ધીમી" કામગીરીને ઓળખવા માટે, અમે કોડ પ્રોફાઇલિંગ કર્યું. આ ડેટાથી સજ્જ, અમે કાં તો mypyc ને ઝટકો કરવાનો પ્રયાસ કર્યો જેથી તે આવી કામગીરી માટે ઝડપી C કોડ જનરેટ કરે, અથવા ઝડપી કામગીરીનો ઉપયોગ કરીને અનુરૂપ પાયથોન કોડને ફરીથી લખી શકે (અને કેટલીકવાર અમારી પાસે તે અથવા અન્ય સમસ્યા માટે પૂરતો સરળ ઉકેલ નહોતો) . કમ્પાઇલર આપમેળે સમાન રૂપાંતરણ કરવા કરતાં પાયથોન કોડને ફરીથી લખવું એ સમસ્યાનો સરળ ઉકેલ હતો. લાંબા ગાળે, અમે આમાંના ઘણા પરિવર્તનોને સ્વચાલિત કરવા માગતા હતા, પરંતુ તે સમયે અમે ન્યૂનતમ પ્રયત્નો સાથે mypy ને ઝડપી બનાવવા પર ધ્યાન કેન્દ્રિત કર્યું હતું. અને આ ધ્યેય તરફ આગળ વધતા, અમે ઘણા ખૂણા કાપી નાખ્યા.

ચાલુ રહી શકાય…

પ્રિય વાચકો! જ્યારે તમે તેના અસ્તિત્વ વિશે શીખ્યા ત્યારે mypy પ્રોજેક્ટ વિશે તમારી શું છાપ હતી?

સોર્સ: www.habr.com