zip در Python دو ورودی را بر اساسِ موقعیت جفت می‌کند و به‌طورِ پیش‌فرض با پایانِ کوتاه‌ترین ورودی متوقف می‌شود. اگر انتظارِ طولِ برابر دارید، strict=True اختلاف را خطا می‌کند؛ اما جفت‌های قبلی ممکن است پیش از خطا تولید شده باشند. این تمرین علاوه بر طول، هویتِ رکوردها و مرزِ ثبتِ نتیجه را با دو فهرستِ اصیل کنترل می‌کند.
سه شناسه در برابرِ دو مقدار
سمتِ چپ سه رکورد با idهایA،B وC داریم؛ سمتِ راست فقطA وB دارد. list(zip(left,right)) دو جفت می‌دهد و دربارهٔCِ باقی‌مانده خطایی نمی‌گوید. این رفتارِ تعریف‌شدهٔ zip است، نه تضمینِ سالم‌بودنِ مجموعهٔ داده. اگر رکوردِ C باید حتماً مقدار داشته باشد، خروجیِ کوتاه برای قراردادِ ما کافی نیست.
ورودی‌ها حداکثر۸رکوردِ ساختگی‌اند. در این صفحه مدل آموزش نمی‌دهیم، ردیفِ پایگاهِ واقعی را جفت نمی‌کنیم و داده‌ای ثبت نمی‌شود. پرسش فقط این است: آیا هر دو مجموعه طبقِ انتظار کامل و هم‌ردیف‌اند، و خطا در چه لحظه‌ای آشکار می‌شود؟
strict خطا می‌دهد، ولی از آغاز ساکت نمی‌ماند
با strict=True حلقه را واقعاً اجرا می‌کنیم و هر جفتِ تولیدشده را در دفترِ مشاهده می‌نویسیم. جفتِ A و سپسB می‌آیند؛ هنگامِ ادامه، ValueError دربارهٔ اختلافِ طول رخ می‌دهد. بنابراین دو خروجیِ قبلی به‌طورِ خودکار پس گرفته نشده‌اند. strict بررسیِ پیشاپیشِ تمامِ ورودی نیست و ماهیتِ lazyِ zip را حذف نمی‌کند.
| حالت | آنچه پیش از پایان دیده شد | نتیجه |
|---|---|---|
| zip عادی با۳و۲رکورد | دو جفت | پایانِ بدون خطای طول |
| strict با۳و۲رکورد | همان دو جفت | سپس ValueError |
| سه رکوردِ هم‌هویت | A،B،C | تأییدِ قراردادِ تمرین |
اگر بدنهٔ حلقه برای هر جفت پیام می‌فرستاد یا جدولِ واقعی را تغییر می‌داد، خطایِ پایانی به‌تنهایی آن اثرها را برنمی‌گرداند. چنین کاری در این آزمایش انجام نشده است. از وجودِ strict، تراکنش یا اجرایِ یک‌بارهٔ ابزار نتیجه نمی‌گیریم.
طولِ برابر با هم‌ردیفی یکی نیست
در ضدنمونهٔ دوم، هر دو طرف سه ردیف دارند اما ترتیبِ سمتِ راست B،A،C است. strict به‌خاطرِ طول خطایی نمی‌بیند؛ با این حال شناسه‌های دو جفتِ نخست برابر نیستند. این بار تابعِ checked پس از ساختِ جفت‌ها، idِ دو طرف را صریح مقایسه و مورد را رد می‌کند.
این سیاست برای fixtureِ دارایِ idِ قابل‌مقایسهٔ ماست. اگر قصد، اتصال بر اساسِ کلید بدونِ وابستگی به ترتیب باشد، باید join و رفتارِ کلیدِ تکراری یا گمشده را جدا طراحی کنید؛ zip خودش key-join انجام نمی‌دهد. مرتب‌کردنِ کورکورانهٔ دو طرف نیز بدونِ قراردادِ هویت، شاهدِ درستیِ مقدارها نیست.
مرحلهٔ بررسی را از مصرفِ نتیجه جدا کنیم
تابعِ محدود ابتدا listِ جفت‌های strict را در staged می‌سازد، سپس برابریِ idها را کنترل می‌کند و فقط در صورتِ موفقیت آن را برمی‌گرداند. فراخواننده در چهار مسیرِ رد چیزی به committed اضافه نمی‌کند: طولِ نابرابر، شناسهٔ ناهم‌ردیف، شناسهٔ تکراری و فیلدِ idِ مفقود. شکلِ هر رکورد و یکتاییِ id در هر طرف پیش از جفت‌سازی کنترل می‌شوند. برای fixtureِ درست، هر سه جفت برمی‌گردند و برای دو فهرستِ خالی، نتیجهٔ خالی پذیرفته می‌شود.
این staging حافظه‌ای رویِ ورودیِ کوچک است. listکردنِ جریانِ نامحدود راه‌حل نیست؛ مرزهایِ قطعه، ذخیرهٔ موقتِ مجاز و تراکنشِ مقصد به طراحیِ دیگری نیاز دارند. نامِ committed در کد فقط دفترِ خالیِ آموزشی است و هیچ دیتابیس، پرداخت، تماس یا پیامِ واقعی به آن وصل نیست.
این کنترل با شمارشِ batch فرق دارد
شمارشِ Epoch،Batch وStep مشخص می‌کند دستهٔ ناقص نگه داشته یا حذف می‌شود؛ اینجا دربارهٔ از دست‌رفتنِ بی‌اعلانِ رکورد در جفت‌کردنِ دو منبع حرف می‌زنیم. اگر حذفِ یک ردیف مجاز است، آن را در قرارداد بنویسید؛ سکوتِ zip جای آن تصمیم نیست.
قراردادِ ویژگیِ مدل معنایِ مقدار و واحد را در دو مسیر بررسی می‌کند. طول و idِ برابر هنوز درست‌بودنِ واحد یا نسخهٔ تبدیل را ثابت نمی‌کنند. برای ادامه در مبانی هوش مصنوعی، ابتدا انتظارِ کامل‌بودن، هویت و ترتیبِ ورودی را ثبت کنید. تمامِ خروجی‌های این صفحه با Python۳٫۱۲٫۱۴ اجرا شده‌اند و قابلیتِ داخلیِ هیچ محصولی را اعلام نمی‌کنند.
فایل تمرین و منبع
کد مستقلِ تمرینِ محدود · تمام خروجیِ واقعیِ همین تمرین؛ JSON
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.