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

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

1. כולם עדיין משתמשים בפייתון 2

הבעיה הראשונה לא קשורה ישירות לשפה אלא למצבה בעולם. רוב חבריי המפתחים בפייתון משתמשים בגירסא 2. כשאנשים מתעניינים בקורס פייתון זה תמיד לגירסא 2. ואם חשבתם שבארץ המצב שונה מבעולם, הגיע בתחילת השנה סקר של דן סטרומברג בו כמעט 7,000 מתכנתי פייתון הבהירו בצורה חד משמעית שב 2014 הם עדיין כותבים בפייתון 2.7. 

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

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

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

פוסט מרתק בנושא מ-2014 מציע גישה אפשרית לפייתון 2.8 ואולי אף 2.9 (שכידוע גווידו מתנגד להן נחרצות). הרעיון הוא לאפשר שדרוג הדרגתי ושבירה איטית יותר של קוד כדי לאפשר למתכנתים לשדרג קוד קיים פיצ׳ר אחרי פיצ׳ר. זה כנראה לא יקרה וכרגע מתכננים לתמוך בפייתון 2.7 עד 2020. לנו נותר רק לחכות.

2. צריך להקליד יותר מדי טקסט בשביל פעולות פשוטות

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

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

do_stuff;
f(\&do_stuff);

לעומת פייתון:

do_stuff()
f(do_stuff)

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

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

sub noop { }

ולעומת זאת בפייתון:

def noop(*args, **kwargs):
     pass

3. מנגנון מחלקות מוגבל

נסו לכתוב מחלקה שתגרום לקוד הבא לעבוד:

a = A()
b = A()

if a is b:
    print "It works"

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

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