הבלוג של ינון פרק

טיפים קצרים וחדשות למתכנתים

טיפ רובי: מילים ואינדקסים במחרוזת

26/07/2025

לרובי אין בעיה להפריד מחרוזת למילים עם אותה פקודת split שאנחנו מכירים גם משפות אחרות:

3.3.5 :027 > "hello world".split
 => ["hello", "world"]

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

3.3.5 :029 > "Don't. go. there".split
 => ["Don't.", "go.", "there"]

שהיה עובד הרבה יותר טוב בלי הנקודות שצמודות למילים. דרך אחת לסדר את זה היא לחפש "התאמות" במקום "הפרדות" ובשביל זה יש לנו את scan:

3.3.5 :032 > "Don't. go. there".scan(/\p{L}+(?:'\p{L}+)*/u)
 => ["Don't", "go", "there"]

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

3.3.5 :036 > text = "Don't means Don't - Don't press the button"
 => "Don't means Don't - Don't press the button"
3.3.5 :037 > third_word = text.scan(/\p{L}+(?:'\p{L}+)*/u)[2]
 => "Don't"
3.3.5 :038 > index_of_third_word = text.index(third_word)
 => 0

זה החזיר 0 כי המילה השלישית זהה למילה הראשונה.

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

3.3.5 :039 > class String
3.3.5 :040 >     def tokenize
3.3.5 :041 >     regex = Regexp.new(/\p{L}+(?:'\p{L}+)*/u)
3.3.5 :042 >
3.3.5 :043 >     Enumerator.new do |y|
3.3.5 :044 >       pos = 0
3.3.5 :045 >       while m = regex.match(self, pos)
3.3.5 :046 >         y << m
3.3.5 :047 >         pos = m.end(0)
3.3.5 :048 >       end
3.3.5 :049 >     end
3.3.5 :050 >   end
3.3.5 :051 > end

3.3.5 :056 > text.tokenize.to_a
 =>
[#<MatchData "Don't">,
 #<MatchData "means">,
 #<MatchData "Don't">,
 #<MatchData "Don't">,
 #<MatchData "press">,
 #<MatchData "the">,
 #<MatchData "button">]

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

3.3.5 :057 > text.tokenize.map { |m| [m.to_s, m.begin(0)] }
 => [["Don't", 0], ["means", 6], ["Don't", 12], ["Don't", 20], ["press", 26], ["the", 32], ["button", 36]]

ובשביל לקבל את אינדקס ההתחלה של המילה השלישית אני כותב:

3.3.5 :060 > text.tokenize.drop(2).first.begin(0)
 => 12

ואם קלוד החזיר לי PR של 700 שורות?

25/07/2025

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

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

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

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

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

פיתוח תוכנה זה עבודה שמורכבת מהמון סוגים של משימות ברמות קושי שונות. יכול להיות שבעתיד יהיה AI שיוכל לפתור את כל הבעיות האלה אבל בינתיים אנחנו לא שם. כשמישהו אומר שהוא נותן לקלוד לכתוב 100% מקוד המערכת או מתאר Flow מסוים לעבודה עם AI ש"תמיד עובד" אני לוקח צעד אחורה.

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

המטרה היא לא לתת לקלוד לכתוב 100% מהקוד. המטרה היא להשתמש בקלוד כדי להתקדם מהר יותר ולבנות מערכות יציבות יותר, יפות יותר וטובות יותר.

לחפש את ה"נכון"

24/07/2025

אחד היתרונות של מפתחים מנוסים שמתחילים לעבוד עם AI הוא היכולת להבדיל בין קודבייס "נכון" לקודבייס מסורבל. מרסל ניומן סיפק דוגמה לכזאת אבחנה בפוסט שפרסם על פיתוח אפליקציית Cross Platform עם React Native.

מרסל הגיע לפרויקט בלי להכיר React Native אבל עם ניסיון של כעשר שנים בפיתוח תוכנה. הוא התחיל עם Vibe Coding, נתן ל AI לבנות הכל, ואז נכנס להסתכל על הקוד, הבין שיש פה בעיה וכמו שהוא מתאר את זה "יחד עם ה AI ביצענו ריפקטור לכל פיצ'ר ביישום עד שהקוד יהיה נקי". התהליך עצמו היה מבחינתו כמו צפייה בסרט - הוא שואל את ה AI שאלות וה AI מלמד אותו ריאקט ו React Native, תוך כדי שהוא מסביר כל פיצ'ר במערכת ודרך השאלות של מרסל גם מבצע את הריפקטורינג לגירסה יותר פשוטה.

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

האם יום אחד נוכל להשתמש ב AI כדי להבין אם AI אחר לא בכיוון ולנווט אותו לכתוב קוד טוב יותר? אני לא יודע. בינתיים זה עוד משהו ששווה לנו להתמקצע בו. ככל שה Feedback Loop של כתיבת קוד מתקצר כך אנחנו יכולים לנסות עוד פרומפטים ועוד Refactor-ים עד שנגיע לאותו קוד שכיף לעבוד עליו.

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

תשומת לב - המיומנות של העשור הבא

23/07/2025

חברה נתנה ל AI לכתוב פיצ'ר שמוחק רווחים מהתחלה או סוף של שם לפני שמירה. ה AI כתב את הקוד וגם כתב לו את הבדיקה הבאה:

test 'Person name with only spaces is trimmed to empty' do
  b = Person.new(name: '   ')
  b.save
  assert_equal('', b.name)
end

הבדיקה עברה ואני קיבלתי את ה PR. הבעיה היחידה? במערכת יש וולידציה שמוודאת ש name לא יכול להיות ריק.

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

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

test 'Person name with only spaces is trimmed to empty' do
  b = Person.new(name: '   ')
  b.valid? # trigger validation to trim b.name
  assert_equal('', b.name)
end

בכל מקרה בעיניי זה היופי בפיתוח בעזרת AI - כשדברים עובדים אני יכול להתמקד באיך לשמור על הקוד נקי כי את עבודת ההקלדה עושה ה AI.

איך לשלוח הודעות עדכון מ Tools ב Vercel AI SDK

22/07/2025

בדוגמה מהאתר של Vercel AI SDK הם מראים איך לקרוא לכלים מתוך הסוכן עם הקוד הבא:

import { z } from 'zod';
import { generateText, tool } from 'ai';

const result = await generateText({
  model: yourModel,
  tools: {
    weather: tool({
      description: 'Get the weather in a location',
      parameters: z.object({
        location: z.string().describe('The location to get the weather for'),
      }),
      execute: async ({ location }) => ({
        location,
        temperature: 72 + Math.floor(Math.random() * 21) - 10,
      }),
    }),
  },
  prompt: 'What is the weather in San Francisco?',
});

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

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

  1. צריך ליצור את ה Stream בצורה יזומה לפני שמפעילים generateText, ואז לחבר את הפלט של generateText ל Stream שיצרנו.

  2. צריך לשים לב ש Vercel AI SDK המציאה פרוטוקול כדי להעביר metadata בשיחה. בכל הודעה יש תחילית של סוג ההודעה ואחריה נקודותיים ואז ההודעה עצמה בתוך מרכאות. התחילית לטקסט היא פשוט 0. לכן היינו יכולים לכתוב משהו כמו:

writer.write('0:"hello"');

אבל יותר קל להשתמש בפונקציה מובנית שלהם שנקראת formatDataStreamPart.

התוצאה נראית כך:

import { openai } from '@ai-sdk/openai';
import { generateId, createDataStreamResponse, streamText, formatDataStreamPart } from 'ai';

import tools from '@/lib/tools';

// Allow streaming responses up to 30 seconds
export const maxDuration = 30;

export async function POST(req: Request) {
  const { messages, data } = await req.json();

  // immediately start streaming (solves RAG issues with status, etc.)
  return createDataStreamResponse({
    execute: dataStream => {
      dataStream.write(formatDataStreamPart('text', 'Warming up!ֿ'));
      dataStream.writeMessageAnnotation({ chunk: 'processing' });

      const result = streamText({
        model: openai('gpt-4-turbo'),
        maxSteps: 5,
        tools: tools(jwtToken, dataStream),
        messages,
        onFinish() {
          // message annotation:
          dataStream.writeMessageAnnotation({
            id: generateId(), // e.g. id from saved DB record
            other: 'information',
          });

          // call annotation:
          dataStream.writeData('call completed');
        },
      });

      result.mergeIntoDataStream(dataStream);
    },
    onError: error => {
      // Error messages are masked by default for security reasons.
      // If you want to expose the error message to the client, you can do so here:
      return error instanceof Error ? error.message : String(error);
    },
  });
}

עכשיו מתוך כל tool אפשר לקרוא ל dataStream.write כדי להוסיף הודעות לשיחה, או לבנות Workflows יותר מורכבים עם מספר סוכנים שכל אחד יוסיף הודעות לשיחה מתוך generateText שלו.

קודבייס ידידותי ל AI

21/07/2025

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

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

  1. שלוש דרכים לעשות X, אבל רק אחת עובדת.

  2. שתי טבלאות ב DB עם שמות דומים שמחזיקות מידע שקשור לדברים אחרים לגמרי.

  3. סקריפט שמריץ את הפרויקט אבל לא את כל רכיבי הפרויקט (כי יש רכיב שאף אחד לא צריך ומי שצריך יודע להריץ אותו לבד).

  4. התקנה שדורשת שינוי ידני ב DB באמצע הדרך.

  5. שפה פנימית ולא מתועדת של צוות הפיתוח.

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

בן האדם שבלופ

20/07/2025

שלוש שיחות עם קלוד-

  1. כתוב קוד פייתון שמתחבר לגיטהאב ומאפשר לי ליצור Issue חדש, להציג את ה Issues הקיימים ולסגור Issue.

קלוד עונה עם קלאס בשם GitHubIssuesManager

  1. למה בחרת לכתוב קלאס? הצג יתרונות וחסרונות של יצירת קלאס מול כתיבת פונקציות והמלץ על ארכיטקטורה.

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

def example_usage():
    """Example of how to use the functions programmatically."""
    config = create_config("your_token", "owner", "repo")

    # Open an issue
    issue = open_issue(config, "Bug found", "Description here", labels=["bug"])

    # List all open issues
    issues = list_issues(config, state="open")

    # Close an issue
    if issues:
        close_issue(config, issues[0]["number"], "Fixed!")
  1. ואיזה משתי הגישות תהיה קלה יותר עבור AI לקרוא ולתחזק?

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

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

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

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

אני אמור לקרוא עכשיו מזהי קומיט?

19/07/2025

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

כן. כשדברים נשברים.

אם אני עובד עם עוד אנשים על פרויקט ושנינו רואים דברים שונים למרות שאנחנו מעודכנים על אותו בראנץ', כדאי שנדע לקרוא את מזהה הקומיט ולהשוות.

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

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

ואז זה עבד

18/07/2025

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

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

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

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

מסתבר שלפחות עבור DHH, ואני בטוח שעבור רבים נוספים, הכיף לא קלקל את הרצון ללמוד אלא להיפך - סביבה לימודית שבה כל דבר עובד יוצרת את הרצון להבין. ה HTML שגרם ל DHH לרצות לכתוב קוד הוא ה Vibe Coding של היום, ואני די בטוח שככל שנחשוף ילדים מגיל צעיר יותר לכלי בניית מוצרים מבוססי AI כך נשפר את הביטחון העצמי והמוטיבציה שלהם.

ספירת שורות בקובץ בפייתון

17/07/2025

הסיפור היום מתחיל כשביקשתי מ ChatGPT להדפיס פונקציה שסופרת כמה שורות יש בקובץ:

def count_lines(filepath):
    with open(filepath, 'r') as f:
        return sum(1 for _ in f)

אבל - איך זה עובד? בואו נפרק את הקוד יחד.

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

>>> open('/etc/passwd', 'r')
<_io.TextIOWrapper name='/etc/passwd' mode='r' encoding='UTF-8'>

פקודת open מחזירה TextIOWrapper. שתי פונקציות העטיפה שלו הן:

>>> f.__enter__
<built-in method __enter__ of _io.TextIOWrapper object at 0x100e879f0>

ו:

>>> f.__exit__
<built-in method __exit__ of _io.TextIOWrapper object at 0x100e879f0>

פקודת ה __exit__ אחראית על סגירת הקובץ והיא מופעלת אוטומטית על ידי פקודת ה with בסיום הבלוק. אני יכול להפעיל אותה ידנית כדי להשתכנע שהקובץ נסגר:

>>> f=open('/etc/passwd', 'r')
>>> f.__exit__()
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

גם השורה השלישית בקוד מסתירה הרבה התנהגות מובנית של השפה. נתחיל עם:

>>> (1 for _ in f)
<generator object <genexpr> at 0x101013ed0>

אם אמרנו ש f הוא TextIOWrapper, אז פקודת for ... in f היא פקודת יצירת גנרטור. היא עדיין לא מפעילה שום לולאה על הקובץ אלא רק מחזירה אוביקט שיודע "לעשות משהו" עם השורות שבקובץ:

>>> f=open('/etc/passwd', 'r')
>>> g=(1 for _ in f)
>>> next(g)
1
>>> next(g)
1
>>> next(g)
1

כל קריאה ל next על הגנרטור מבצעת איטרציה בודדת של האוביקט. במקרה של TextIOWrapper, איטרציה בודדת היא קריאה של מידע מהקובץ עד לגודל החוצץ המקסימלי (מוגדר ב io.DEFAULT_BUFFER_SIZE), חיפוש השורה הבאה והחזרת אותה השורה. הגנרטור עוטף את ההתנהגות הזאת ומחזיר משהו אחר במקום השורה. נתבונן רגע בגנרטור הפשוט יותר:

>>> g=(line for line in f)
>>> next(g)
'# Note that this file is consulted directly only when the system is running\n'
>>> next(g)
'# in single-user mode.  At other times this information is provided by\n'
>>> next(g)
'# Open Directory.\n'

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

השורה המלאה:

return sum(1 for _ in f)

מפעילה את sum על גנרטור. זה מעניין! אנחנו רגילים להפעיל sum על רשימות:

>>> sum([10, 20, 30, 40])
100

כשמפעילים sum על גנרטור פייתון לא הופך אותו לרשימה אלא יודע לרוץ בלולאה ולהוסיף למונה כל פעם את הערך הבא מהגנרטור. זה דומה ללולאה הבאה:

>>> f=open('/etc/passwd', 'r')
>>> g=(1 for line in f)
>>> line_count = 0
>>> for value in g:
...     line_count += 1
...
>>> line_count
140

למעשה אם היינו כותבים לולאה כנראה שלא היינו מגדירים את הגנרטור ומראש כותבים לולאה כזאת:

def count_lines(filepath):
    with open(filepath, 'r') as f:
        line_count = 0
        for line in f:
            line_count += 1
        return line_count

הגנרטור אפשר לארגן מחדש את המבנה בצורה שיותר מתאימה ל sum וכך הצלחנו לכתוב:

def count_lines(filepath):
    with open(filepath, 'r') as f:
        return sum(1 for _ in f)

כי האיטרציה מבוצעת בתוך הפונקציה sum.

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