یک نام در پایتون نوع ندارد؛ مقداری که در آن نشسته نوع دارد. nerkh = 12000 و بعد nerkh = "davazdah hezar" هر دو مجازند و type(nerkh) هر بار درباره مقدار همان لحظه جواب میدهد. نتیجه عملیاش این است که خطای نوع همیشه سر عملیات میآید، نه سر انتساب.
سه سطر که یک ستون مبلغ را از یک خروجی فارسی میخوانند، و فقط یکیشان خطا میدهد:
int("۱۲۰۰۰")عدد ۱۲۰۰۰ را برمیگرداندint("۱۲٬۰۰۰")باValueErrorمیایستدint("12,000")هم با همانValueError: invalid literal for int() with base 10میایستد
پایتون هر رقم دهدهی یونیکد را میپذیرد، پس رقم فارسی برایش عدد است. چیزی که نمیپذیرد جداکننده هزارگان است، فارسی یا لاتین فرقی ندارد. برای همین یک خروجی که ارقامش فارسی است بیدردسر خوانده میشود و همان خروجی با جداکننده در همان ستون میشکند، و پیام خطا از جداکننده حرف میزند نه از زبان.
خطا دادن سر همان سطر، یک ویژگی است
در جاوااسکریپت همین کار خطا نمیدهد. parseInt("12,000") عدد ۱۲ را برمیگرداند و هیچ اعتراضی نمیکند، و آن ۱۲ تا آخر برنامه سفر میکند و در یک جمع یا یک فاکتور بیرون میآید. همینطور "3" + 4 در پایتون TypeError: can only concatenate str (not "int") to str میدهد و در جاوااسکریپت رشته "34" میشود.
این دو محور جدا هستند و معمولاً یکی گرفته میشوند: اینکه بررسی کی انجام شود، و اینکه وقتی نوع نمیخواند چه اتفاقی بیفتد. محور دوم آن است که تعیین میکند یک مقدار غلط تا کجا جلو میرود.
حاشیهنویسی نوع ثبت میشود و بررسی نمیشود
نوشتن def nerkh(t: int) -> int: هیچ چیزی را در زمان اجرا اجباری نمیکند. صدا زدنش با یک رشته کار میکند و همان رشته را برمیگرداند؛ حاشیهنویسی فقط در nerkh.__annotations__ ثبت شده است. کسی که این را نمیداند فکر میکند یک بررسی گذاشته و نگذاشته. اجرایی کردن آن کار یک ابزار جداست، و زبانی که همین ایده را از اول در خودش دارد موضوع نوعها روی جاوااسکریپت، و چیزی که میگیرند است.
بولین یک عدد است، و این یک کلید را میبلعد
isinstance(True, int) جواب میدهد True، چون در پایتون بولین زیرمجموعه عدد صحیح است. پیامدش جایی بیرون میزند که انتظارش را ندارید: {1: "naghdi", True: "kart"} یک دیکشنری با یک کلید است و مقدارش kart، چون کلید دوم با کلید اول برابر بود و رویش نوشت. اگر شماره روش پرداخت و یک پرچم بله و خیر در یک نگاشت کنار هم بنشینند، یکی از آن دو کلید بیصدا از بین میرود. جایی که این قاعده کلید را تعیین میکند جستوجو با کلید، و عضویت در زمان ثابت است.
جایی که کار گیر میکند، فایل خروجی فارسی است
اولین داده واقعی که یک برنامهنویس در ایران میخواند تقریباً همیشه یک خروجی از یک سامانه فارسی است: ارقام فارسی، جداکننده هزارگان، گاهی یک فاصله مجازی وسط یک نام ستون، و تاریخ شمسی در ستون کناری. آموزشها با فایلهای تمیز انگلیسی کار میکنند و این حالت را اصلاً نمیبینند، پس اولین ValueError شبیه یک اشکال در خود پایتون به نظر میرسد. نیست. عادتی که همه چیز را عوض میکند این است که پیش از تبدیل، رشته را تمیز کنید و در همان جا شکست را بپذیرید، نه سه تابع جلوتر که دیگر معلوم نیست عدد از کدام سطر آمده.
ابزار، و سالی که این حرف درست است
در سال ۲۰۲۶ برای اینکه حاشیهنویسیها واقعاً بررسی شوند، ابزار جاافتاده mypy است که بیرون از زمان اجرا و روی متن برنامه کار میکند و جای این باور را گرفته که خود مفسر آنها را بررسی میکند. رایگان و متنباز است و پس از نصب به شبکه کاری ندارد. رقیب تازهترش که به همان حاشیهنویسیها نگاه میکند و بسیار سریعتر است ty از سازندگان ruff است. هر دو بیرون از برنامهاند: هیچکدام رفتار زمان اجرا را عوض نمیکنند.
پرسش بعدی این است که وقتی تبدیل شکست خورد چه کار باید کرد و چطور میشود شکست را جایی گرفت که هنوز معلوم است از کجا آمده، که شکست پرصدا، شکست بیخطر، و فرق این دو جوابش است. و اینکه آن مقدارها بعد از ساخته شدن کجا مینشینند، مقدارها کجا مینشینند و چه وقت آزاد میشوند.