הנתיב לבדיקת סוג 4 מיליון שורות של קוד Python. חלק 1

היום אנו מביאים לידיעתכם את החלק הראשון של התרגום של החומר על האופן שבו דרופבוקס מתמודדת עם בקרת סוגים של קוד Python.

Dropbox כותב הרבה ב-Python. זוהי שפה שאנו משתמשים בה באופן נרחב ביותר, הן עבור שירותי קצה והן עבור יישומי לקוח שולחניים. אנחנו גם משתמשים הרבה ב-Go, TypeScript ו-Rust, אבל Python היא השפה העיקרית שלנו. בהתחשב בקנה המידה שלנו, ואנחנו מדברים על מיליוני שורות של קוד Python, התברר שההקלדה הדינמית של קוד כזה סיבך את ההבנה שלו שלא לצורך והחלה להשפיע באופן רציני על פריון העבודה. כדי להקל על בעיה זו, התחלנו להעביר בהדרגה את הקוד שלנו לבדיקת סוג סטטי באמצעות mypy. זוהי כנראה מערכת הבדיקה העצמאית הפופולרית ביותר עבור Python. Mypy הוא פרויקט קוד פתוח, המפתחים העיקריים שלו עובדים בדרופבוקס.

Dropbox הייתה אחת החברות הראשונות שהטמיעו בדיקת סוגים סטטית בקוד Python בקנה מידה זה. Mypy משמש באלפי פרויקטים בימים אלה. הכלי הזה אינספור פעמים, כמו שאומרים, "נוסה בקרב". עשינו דרך ארוכה כדי להגיע למקום בו אנו נמצאים כעת. לאורך הדרך, היו הרבה התחייבויות לא מוצלחות וניסויים כושלים. פוסט זה מכסה את ההיסטוריה של בדיקת סוגים סטטיים ב-Python, מההתחלה הקשה שלה כחלק מפרויקט המחקר שלי, ועד היום, כאשר בדיקת סוגים ורמזים לסוג הפכו לדבר שבשגרה עבור אינספור מפתחים שכותבים ב-Python. מנגנונים אלה נתמכים כעת על ידי כלים רבים כגון IDEs ומנתחי קוד.

→ קרא את החלק השני

מדוע יש צורך בבדיקת סוג?

אם אי פעם השתמשת ב-Python מוקלדת דינמית, אולי יש לך קצת בלבול מדוע יש כל כך מהומה סביב הקלדה סטטית ו-mypy לאחרונה. או שאולי אתה אוהב את Python בדיוק בגלל ההקלדה הדינמית שלו, ומה שקורה פשוט מרגיז אותך. המפתח לערך של הקלדה סטטית הוא קנה המידה של הפתרונות: ככל שהפרויקט שלך גדול יותר, כך אתה נוטה יותר לכיוון הקלדה סטטית, ובסופו של דבר, אתה באמת צריך את זה יותר.

נניח שפרויקט מסוים הגיע לגודל של עשרות אלפי שורות, והתברר שעובדים עליו כמה מתכנתים. בהסתכלות על פרויקט דומה, בהתבסס על הניסיון שלנו, אנו יכולים לומר שהבנת הקוד שלו תהיה המפתח לשמירה על פרודוקטיביות של מפתחים. ללא הערות סוג, יכול להיות קשה להבין, למשל, אילו ארגומנטים להעביר לפונקציה, או אילו סוגים פונקציה יכולה להחזיר. להלן שאלות טיפוסיות שלעתים קרובות קשה לענות עליהן מבלי להשתמש בהערות סוג:

• האם פונקציה זו יכולה לחזור None?
• מה צריך להיות הטיעון הזה? items?
• מהו סוג התכונה id: int האם זה, str, או אולי סוג מותאם אישית?
• האם הטיעון הזה צריך להיות רשימה? האם אפשר להעביר לזה טופלה?

אם אתה מסתכל על קטע הקוד הבא עם הערות טיפוס ומנסה לענות על שאלות דומות, מתברר שזו המשימה הפשוטה ביותר:

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata לא חוזר None, מכיוון שסוג ההחזרה אינו Optional[…].
• טיעון items הוא רצף של קווים. אי אפשר לחזור על זה באופן אקראי.
• תכונה id הוא מחרוזת של בתים.

בעולם אידיאלי, אפשר היה לצפות שכל הדקויות הללו יתוארו בתיעוד המובנה (דוקstring). אבל הניסיון נותן הרבה דוגמאות לעובדה שלעיתים קרובות תיעוד כזה אינו נצפה בקוד שאיתו אתה צריך לעבוד. גם אם תיעוד כזה קיים בקוד, אי אפשר לסמוך על נכונותו המוחלטת. תיעוד זה יכול להיות מעורפל, לא מדויק ופתוח לאי הבנות. בצוותים גדולים או בפרויקטים גדולים, בעיה זו עלולה להיות חריפה ביותר.

בעוד ש-Python מצטיינת בשלבים מוקדמים או ביניים של פרויקטים, בשלב מסוים פרויקטים מוצלחים וחברות המשתמשות ב-Python עלולים להתמודד עם השאלה החיונית: "האם עלינו לשכתב הכל בשפה מוקלדת סטטית?".

מערכות בדיקת סוגים כמו mypy פותרות את הבעיה שלעיל על ידי מתן שפה רשמית למפתח לתיאור טיפוסים, ועל ידי בדיקה שהצהרות הסוג תואמות ליישום התוכנית (ואופציונלי, בדיקת קיומן). באופן כללי, אנו יכולים לומר שמערכות אלו מעמידות לרשותנו משהו כמו תיעוד שנבדק בקפידה.

לשימוש במערכות כאלה יש יתרונות נוספים, והם כבר לגמרי לא טריוויאליים:

• מערכת בדיקת הסוג יכולה לזהות כמה שגיאות קטנות (ולא כל כך קטנות). דוגמה טיפוסית היא כאשר הם שוכחים לעבד ערך None או מצב מיוחד אחר.
• שינוי קוד מחדש מפושט מאוד מכיוון שמערכת בדיקת הסוגים לרוב מדויקת מאוד לגבי הקוד שצריך לשנות. יחד עם זאת, אנחנו לא צריכים לקוות לכיסוי קוד של 100% עם בדיקות, שבכל מקרה, בדרך כלל לא ניתן לביצוע. אנחנו לא צריכים להתעמק במעמקי עקבות הערימה כדי לגלות את הסיבה לבעיה.
• אפילו בפרויקטים גדולים, mypy יכולה לעתים קרובות לבצע בדיקת סוגים מלאה בשבריר שנייה. וביצוע הבדיקות לוקח בדרך כלל עשרות שניות או אפילו דקות. מערכת בדיקת הסוג נותנת למתכנת משוב מיידי ומאפשרת לו לבצע את עבודתו מהר יותר. הוא כבר לא צריך לכתוב בדיקות יחידה שבריריות וקשות לתחזוקה שמחליפות ישויות אמיתיות בלעג ותיקונים רק כדי לקבל תוצאות בדיקות קוד מהר יותר.

IDE ועורכים כגון PyCharm או Visual Studio Code משתמשים בכוחם של הערות סוגים כדי לספק למפתחים השלמת קוד, הדגשת שגיאות ותמיכה בבניית שפה נפוצה. ואלה רק חלק מהיתרונות של ההקלדה. עבור חלק מהמתכנתים, כל זה הוא הטיעון העיקרי בעד הקלדה. זה משהו שמרוויח מיד לאחר היישום. מקרה שימוש זה עבור טיפוסים אינו מצריך מערכת נפרדת לבדיקת סוגים כגון mypy, אם כי יש לציין כי mypy מסייע לשמור על הערות סוג עקביות עם קוד.

רקע של mypy

ההיסטוריה של mypy התחילה בבריטניה, בקיימברידג', כמה שנים לפני שהצטרפתי לדרופבוקס. הייתי מעורב, כחלק ממחקר הדוקטורט שלי, באיחוד של שפות מוקלדות סטטיות ודינמיות. קיבלתי השראה ממאמר על הקלדה מצטברת של ג'רמי סייק ו-וואליד טאהא, ומפרויקט המחבט הקלד. ניסיתי למצוא דרכים להשתמש באותה שפת תכנות עבור פרויקטים שונים – מסקריפטים קטנים ועד בסיסי קוד המורכבים ממיליונים רבים של שורות. יחד עם זאת, רציתי להבטיח שבפרויקט בכל קנה מידה לא יצטרך להתפשר יותר מדי. חלק חשוב מכל זה היה הרעיון לעבור בהדרגה מפרויקט אב טיפוס לא מודפס למוצר מוגמר מודפס סטטי שנבדק מקיף. בימים אלה, הרעיונות הללו מובנים מאליהם, אבל ב-2010 זו הייתה בעיה שעדיין נחקרה באופן פעיל.

העבודה המקורית שלי בבדיקת סוגים לא הייתה מכוונת לפייתון. במקום זאת, השתמשתי בשפה קטנה "תוצרת בית". עוד. הנה דוגמה שתאפשר לך להבין על מה אנחנו מדברים (הערות סוג הן אופציונליות כאן):

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

שימוש בשפת אם מפושטת היא גישה נפוצה במחקר מדעי. זה כך, לא מעט בגלל העובדה שזה מאפשר לך לבצע במהירות ניסויים, וגם בשל העובדה שניתן להתעלם בקלות ממה שאין לו שום קשר למחקר. שפות תכנות בעולם האמיתי נוטות להיות תופעות בקנה מידה גדול עם יישומים מורכבים, מה שמאט את הניסויים. עם זאת, כל תוצאות המבוססות על שפה מפושטת נראות מעט חשודות, שכן בהשגת תוצאות אלו החוקר אולי הקריב שיקולים חשובים לשימוש מעשי בשפות.

בודק הסוג שלי עבור Alore נראה מבטיח מאוד, אבל רציתי לבדוק אותו על ידי ניסוי עם קוד אמיתי, שאפשר לומר שלא נכתב ב-Alore. למזלי, שפת Alore התבססה במידה רבה על אותם רעיונות כמו פייתון. היה קל מספיק לשנות את בודק הסוג כדי שיוכל לעבוד עם התחביר והסמנטיקה של Python. זה איפשר לנו לנסות להקליד צ'ק בקוד קוד פתוח של Python. בנוסף, כתבתי טרנספילר כדי להמיר קוד שנכתב ב-Alore לקוד Python והשתמשתי בו כדי לתרגם את קוד ה-typechecker שלי. עכשיו הייתה לי מערכת בדיקת סוגים שנכתבה בפייתון שתמכה בתת-קבוצה של פייתון, איזושהי שפה כזו! (החלטות ארכיטקטוניות מסוימות שהיו הגיוניות עבור Alore לא התאימו לפייתון, וזה עדיין מורגש בחלקים מבסיס הקוד של mypy.)

למעשה, השפה הנתמכת על ידי מערכת הסוג שלי לא ממש יכולה להיקרא Python בשלב זה: היא הייתה גרסה של Python עקב מגבלות מסוימות של תחביר ההערות מסוג Python 3.

זה נראה כמו תערובת של ג'אווה ופייתון:

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

אחד הרעיונות שלי באותה תקופה היה להשתמש בהערות סוג כדי לשפר את הביצועים על ידי קומפילציה מסוג זה של Python ל-C, או אולי JVM bytecode. הגעתי לשלב של כתיבת אב טיפוס מהדר, אבל נטשתי את הרעיון הזה, מכיוון שבדיקת הסוג עצמו נראתה שימושית למדי.

בסופו של דבר הצגתי את הפרויקט שלי ב-PyCon 2013 בסנטה קלרה. דיברתי על זה גם עם גווידו ואן רוסום, דיקטטור הפייתון הנדיב לכל החיים. הוא שכנע אותי להוריד את התחביר שלי ולהישאר עם התחביר הסטנדרטי של Python 3. Python 3 תומך בהערות פונקציות, כך שניתן לשכתב את הדוגמה שלי כפי שמוצג להלן, וכתוצאה מכך תוכנית Python רגילה:

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

הייתי צריך לעשות כמה פשרות (קודם כל, אני רוצה לציין שהמצאתי את התחביר שלי בדיוק מהסיבה הזו). במיוחד, Python 3.3, הגרסה העדכנית ביותר של השפה באותה תקופה, לא תמכה בהערות משתנות. שוחחתי עם Guido בדואר אלקטרוני על אפשרויות שונות לעיצוב תחבירי של הערות כאלה. החלטנו להשתמש בהערות מסוג עבור משתנים. זה שירת את המטרה המיועדת, אבל היה קצת מסורבל (Python 3.6 נתן לנו תחביר יפה יותר):

products = []  # type: List[str]  # Eww

הערות סוג הועילו גם לתמיכה ב-Python 2, שאין לה תמיכה מובנית בהערות סוג:

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

התברר שהחילופים הללו (ואחרים) לא ממש חשובים - היתרונות של הקלדה סטטית גרמו לכך שהמשתמשים שכחו במהרה את התחביר הפחות ממושלם. מכיוון שלא נעשה שימוש במבנים תחביריים מיוחדים בקוד Python שנבדק על ידי סוגים, הכלים הקיימים של Python ותהליכי עיבוד הקוד המשיכו לעבוד כרגיל, מה שהקל הרבה יותר על מפתחים ללמוד את הכלי החדש.

גידו גם שכנע אותי להצטרף לדרופבוקס לאחר שסיימתי את עבודת התואר שלי. כאן מתחיל החלק המעניין ביותר בסיפור mypy.

להמשך ...

קוראים יקרים! אם אתה משתמש ב-Python, אנא ספר לנו על היקף הפרויקטים שאתה מפתח בשפה זו.

מקור: www.habr.com