آزمودن و تحویل34 از 37
برای خواننده‌هایی که کمی پایتون بلدند.
در درس «آزمودنِ یک عامل» دیدید چرا یک eval هر کار را چند بار اجرا می‌کند: یک کار ممکن است در یک اجرا قبول شود و در اجرای بعد رد. این‌جا بخشی را می‌نویسید که انبوهی از سابقه‌ی اجراها را به گزارشی تبدیل می‌کند که بشود بر اساسش کاری کرد.
ورودی. هر خط یک اجرا: نامِ کار، pass یا fail، و هزینه‌ی آن اجرا به دلار. خط‌های خالی و خط‌هایی که با # شروع می‌شوند کنار گذاشته می‌شوند (این بخش برایتان نوشته شده).
fix-test pass 0.40
fix-test fail 0.52
add-readme pass 0.10
چه چیزی چاپ شود. تابعِ grade(records) را بنویسید که خط‌های گزارش را برمی‌گرداند:
- برای هر کار یک خط، به ترتیبی که هر کار اولین بار آمده: چند اجرا قبول شده، به شکلِ کسر و درصدِ گرد، کلِ هزینه‌ی کار، و هزینه‌ی آن برای هر قبولی (کلِ هزینه تقسیم بر تعدادِ قبولی‌ها)، یا no passes. مثلاً fix-test: 4/5 passed (80%), 2.04 dollars, 0.51 per pass.
- flaky: و کارهایی که در بعضی اجراها قبول و در بعضی رد شده‌اند، جداشده با , ، یا none.
- always failing: و کارهایی که هیچ‌وقت قبول نشده‌اند، یا none.
- total: تعدادِ اجراها، چندتا قبول شده همراهِ درصد، و کلِ هزینه: total: 10 runs, 9 passed (90%), 2.54 dollars.
درصدها بی‌اعشارند (f"{x:.0f}") و دلارها با دو رقمِ اعشار (f"{x:.2f}").
چرا برای هر قبولی؟ کارِ ارزانی که نیمی از وقت‌ها شکست می‌خورد، ممکن است برای هر موفقیت گران‌تر از کارِ پرهزینه‌ای تمام شود که همیشه درست درمی‌آید. هزینه‌ای که واقعاً برایتان مهم است، هزینه‌ی یک کارِ تمام‌شده است، با شکست‌ها.
چرا ناپایدار مهم است. کاری که همیشه رد می‌شود به شما می‌گوید چیزی کم است: یک ابزار، یک اجازه، یک دستور. کارِ ناپایدار از جهتی بدتر است، چون یک اجرا نمی‌تواند بگوید یک تغییر کمک کرده یا نه. این‌ها کارهایی‌اند که باید بیشتر اجرایشان کرد، و اولین جایی که وقتِ تغییرِ پرامپت سیستمی یا مدل باید نگاه کنید.
ورود برای امتحان این تمرین.