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

הקוד הבא מבלבל:

let x = "hello, "
x += "world"
console.log(x);

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

קל להיווכח בזה באמצעות הוספת משתנה:

> x = "hello, "
'hello, '
> y = x
'hello, '
> x += "world"
'hello, world'
> x
'hello, world'
> y
'hello, '

אם ה += היה משנה את המחרוזת אז היינו רואים את השינוי גם ב y, בדיוק כמו שקורה בעבודה על מערכים:

> x = [1, 2, 3]
[ 1, 2, 3 ]
> y = x
[ 1, 2, 3 ]
> x.push(4)
4
> x
[ 1, 2, 3, 4 ]
> y
[ 1, 2, 3, 4 ]

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

דוגמה? תמיד. הקוד הבא מייצר כפתור שבלחיצה עליו יקפיץ הודעת alert:

const main  = document.querySelector('main');
main.innerHTML += '<button>button 1</button>';
main.querySelector('button').addEventListener('click', () => {
  alert('1');
})

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

const main  = document.querySelector('main');
main.innerHTML += '<button>button 1</button>';
main.querySelector('button').addEventListener('click', () => {
  alert('1');
});

main.innerHTML += '<p>Click for magic</p>';

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

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

const id = searchParams.id || throw new Error("id is required");

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

open FILE, "filename.txt" or die "Cannot open file: $!\n";

או:

chdir('/etc') or die "Can't change directory";

אז למה בעצם לא היינו צריכים את זה ב JavaScript? כמה השערות-

1. אנחנו פחות זורקים שגיאות ב JavaScript - בניגוד ל perl שם כשמנסים להריץ סקריפט מי שהריץ את הסקריפט רואה את השגיאה ועוד יכול לעשות משהו, ב JavaScript זריקה של Exception במצב כזה פשוט תציג שגיאה לקונסול, ורוב הזמן אף אחד לא יראה אותה. לכן רוב הזמן הטיפול בשגיאות ב JavaScript הוא מקומי.

2. לפעמים יותר נוח להשתמש ב Destructuring כי ממילא יהיה לנו עוד מידע להוציא מהאוביקט, משהו כמו:

const { id, page, limit } = searchParams;
if (!id) {
    throw new Error("id is required");
}

מה אתכם? יצא לכם להתגעגע למבנה של || throw ב JavaScript? אם כן ספרו מתי, ואם לא ספרו מה עשיתם במקום.

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

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

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

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

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

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

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

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

def longer_than(n: int, items: list[str]) -> list[str]:
    return [I for I in items if len(i) > n]

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

print(longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10))))

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

def longer_than(n: int, items: Iterable[Sized]) -> list[Sized]:
    return [I for I in items if len(i) > n]


print(longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10))))

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

long_items = longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10)))
print(long_items[0][0])

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

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

T = TypeVar('T', bound=Sized)  
def longer_than(n: int, items: Iterable[T]) -> list[T]:
    return [I for I in items if len(i) > n]

long_items1 = longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10)))
print(long_items1[0][0])  

long_items2 = longer_than(3, ['abc', 'abcdefg', 'as'])
print(long_items2[0].capitalize())

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

״איך את בונה תיבה עם השלמה אוטומטית שתהיה נגישה?״

״איך אתה בונה Checkbox שישתמש בתמונה מותאמת אישית וגם יאפשר ניווט מקלדת?״

״איך תבני גלריית תמונות ב HTML/CSS אם כל התמונות בגדלים שונים?״

״איך תציג על המסך תמונה עם אפקט Scale כשעוברים עליה עם העכבר?״

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

היכולת של Chat GPT או בינג (או Copilot במידת מיומנות פחותה) ליצור תבניות התחלה וקטעי קוד קטנים שעובדים צריכה לשנות את כל הגישה שלנו לעבודה. אי אפשר להישאר אדישים.

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

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

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

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

״מה עבד לך?. אולי חלק מזה יעבוד גם לי (ואולי לא, וזה גם בסדר).״

שגיאת כתיב מקרית בהתקנת חבילות הובילה אותי לקובץ cmd-list.js במאגר npm/cli, ומשם לקטע הבא מתוך אוביקט aliases:

in: 'install',
ins: 'install',
inst: 'install',
insta: 'install',
instal: 'install',
isnt: 'install',
isnta: 'install',
isntal: 'install',
isntall: 'install',

מה קורה כאן? אז הכי אחורה שהצלחתי להגיע עם זה היה ה PR הזה שהוסיף את ה alias בשביל לא להרגיז את אלכס סקסטון. אותו אלכס אגב פירסם באיזה גיסט מאותה תקופה את הלוג הבא מעבודה עם npm עם הכותרת How Dare You:

$ npm isntall
npm ERR! Darwin 14.0.0
npm ERR! argv "node" "/Users/alexsexton/.nave/installed/0.10.33/bin/npm" "isntall"
npm ERR! node v0.10.33
npm ERR! npm  v2.1.7
npm ERR! code MODULE_NOT_FOUND

npm ERR! Cannot find module '/Users/alexsexton/.nave/installed/0.10.33/lib/node_modules/npm/lib/isntall.js'
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <http://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/alexsexton/stripe/dashboard-ui/npm-debug.log

לימים נוספו עוד alias-ים נוספים ל install ולפקודות רבות נוספות, כשההסבר הרשמי לכולם (מתוך הדיון כאן) הוא:

npm is not here to punish people for spelling mistakes. npm is here to install your packages, even if you type "isntall".

גישה חיובית ולא מאוד נפוצה.

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

#[macro_use] extern crate rocket;

#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![hello])
}

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

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

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

#[get("/sensitive")]
fn sensitive(key: ApiKey) { /* .. */ }

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

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

/// This route is chosen if the request guard for User passes (e.g. logged in).
#[get("/")]
fn home(user: User, _cookies: Cookies) -> Markup {
    html! {
        head {
            title {"Welcome | Auth0 Rocket Example"}
            link rel="stylesheet" href="static/css/style.css";
        }
        body{
            h1 {"Guarded Route"}
            div {p {
                "You logged in successfully."
            }}
            div {p {
                "Email: " (user.email)
            }}
            div {p {
                a class="login" href="/profile" {"Another private route"}
            }}
        }
    }
}

כשהקוד של User הוא:

#[derive(Debug, Serialize, Deserialize)]
struct User {
    user_id: String,
    email: String,
}

impl<'a, 'r> FromRequest<'a, 'r> for User {
    type Error = ();
    fn from_request(request: &'a Request<'r>) -> Outcome<User, ()> {
        let session_id: Option<String> = request
            .cookies()
            .get("session")
            .and_then(|cookie| cookie.value().parse().ok());
        match session_id {
            None => {
                println!("no session id");
                rocket::Outcome::Forward(())
            }
            Some(session_id) => {
                println!("session id: {}", session_id);
                let db = State::<DB>::from_request(request).unwrap();
                let session_key = make_key!("sessions/", session_id);
                match db.get(&session_key.0) {
                    Ok(Some(sess)) => {
                        let sess: Session =
                            deserialize(&sess).expect("could not deserialize session");
                        if sess.expired() {
                            return rocket::Outcome::Forward(());
                        }
                        let user_key = make_key!("users/", sess.user_id);
                        match db.get(&user_key.0) {
                            Ok(Some(user)) => {
                                let user: User =
                                    deserialize(&user).expect("could not deserialize user");
                                rocket::Outcome::Success(user)
                            }
                            _ => rocket::Outcome::Forward(()),
                        }
                    }
                    _ => rocket::Outcome::Forward(()),
                }
            }
        }
    }
}

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

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

def show
    @post = Post.find(params[:id])
    authorize! :read, @post
    render plain: "Welcome #{current_user.name}"
end

או ל Express שם אפשר להשתמש ב Middlewares בשורת הגדרת הפונקציה:

app.get('/post/:id', authorize_user, (req, res) => {
    const user = res.locals.user;
    res.send(`Welcome! ${user.name}`);
});

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

בכתיבת תוכניות גרפיות עם Qt ב Python נוכל לשים לב שפעולות ארוכות ״תוקעות״ את התוכנית. לדוגמה נדמיין תוכנית המציגה תיבת חיפוש לקבצים, כפתור ורשימה ובלחיצה על הכפתור התוכנית מחפשת קבצים שמתאימים לשם הקובץ שבתיבה וממלאת את הרשימה בשמות הקבצים שנמצאו.

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

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

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

2. פיתרון יותר כללי יהיה לפתוח Thread נוסף ולבצע את הלולאה (במקרה שלנו לולאת חיפוש) מתוך ה Thread הנוסף.

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

קוד? ברור, ומספיק קובץ אחד:

from PySide6.QtCore import *
from PySide6.QtGui import *
from PySide6.QtWidgets import *
from pathlib import Path
from time import sleep

class Finder(QObject):
    path_found = Signal(str)

    def __init__(self, parent=None):
        super().__init__(parent)

    def search(self, text):
        results = Path('.').rglob(text)

        for result in results:
            self.path_found.emit(str(result.absolute()))
            sleep(0.01)



class Ui(QWidget):
    start_search = Signal(str)

    def __init__(self, parent=None):
        super().__init__(parent)
        self.results = QListWidget()
        self.searchbox = QLineEdit()
        self.search_button = QPushButton("Search")
        self.finder = Finder()
        self.finder_thread = QThread(self)
        self.finder.moveToThread(self.finder_thread)
        self.finder_thread.start()

        self.main_layout = QVBoxLayout(self)
        self.top_layout = QHBoxLayout()
        self.main_layout.addLayout(self.top_layout)

        self.top_layout.addWidget(self.searchbox)
        self.top_layout.addWidget(self.search_button)
        self.main_layout.addWidget(self.results)

        self.search_button.clicked.connect(self.search)

        self.start_search.connect(self.finder.search)
        self.finder.path_found.connect(self.results.addItem)

    def search(self):
        self.results.clear()
        self.start_search.emit(self.searchbox.text())

    def closeEvent(self, event):
        self.finder_thread.exit(0)



app = QApplication()
w = Ui()
w.show()
app.exec()

אז מה היה לנו כאן?

1. האוביקט Finder אחראי על חיפוש הקבצים. הוא יורש מ QObject כי ככה Qt דורש. הפונקציה moveToThread שלו שולחת אותו לעבוד ב Thread אחר.

2. ה Thread אגב הוא Thread של Qt ולא של פייתון. נוצר באמצעות QThread().

3. ה Widget הראשי מגדיר סיגנל כדי לאותת ל Finder שצריך להתחיל את החיפוש, וה Finder מגדיר סיגנל כדי לאותת ל Widget הראשי שהוא מצא קובץ.

4. השורות שמחברות את הסיגנלים לקודי הטיפול מופעלות ב init של ה Widget והן:

self.start_search.connect(self.finder.search)
self.finder.path_found.connect(self.results.addItem)

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

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

def closeEvent(self, event):
    self.finder_thread.exit(0)

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