اهمیت پیوستگی در کد پایتونی شما

این بخشی از مجموعه‌ای بخصوص راجع به محیط پایتون است که بر اصول شماره ۱۲، ۱۳ و ۱۴ یعنی: نقش ابهام و بدیهیات، متمرکز است.

اصل حداقل غافل گیری، راهبردی در خلال طراحی رابط‌های کاربری است. طبق این اصل هنگامی کاربر عملیاتی انجام می‌دهد، برنامه باید هرکاری می‌تواند بکند که کاربر حداقل غافل‌گیری را تجربه نماید. این به همان دلیلی است که بچه ها عاشق چند باره خوانی یک کتاب هستند: هیچ چیز بیشتر از داشتن توانایی پیش‌بینی کردن و دیدن اینکه آن پیش‌بینی ها درست از آب در می‌آیند برای مردم آرامش‌بخش نیست.

نگرش بنیادی در توسعه‌ی زبان ABC، الهام بخش پایتون، این بود که زبان‌های برنامه‌نویسی رابط های کاربری هستند، و باید همان ابزاری طراحی شوند که توسط طراحان رابط های کاربری استفاده می‌شود.

خوشبختانه، از آن زمان به بعد زبان‌های بیشتری مفاهیم استطاعت و زبان طراحی ماشین «ارگونومی» را از طراحی رابط‌های کاربری گرفتند؛ حتی اگر با درجه سختی کمتری آن‌ها را اعمال کنند.

این ما را به سه مفهوم بعدی در محیط پایتون می‌رساند.

در مواجهه با ابهام، اسیر وسوسه حدس زدن نشوید.

حاصل ۱+"۱" باید چه باشد؟ هم "۱۱" حدس درستی است، هم ۲. این عبارت مبهم است. هیچ کاری نیست که بتواند انجام دهد تا دسته کم برای عده‌ای از مردم، متعجب کننده نباشد.

برخی زبانها از حدس زدن استفاده میکنند. در جاوااسکریپت نتیجه "۱۱" است. در پرل حاصل ۲ است. در C، به طور طبیعی نتیجه رشته‌ای خالی است. در مواجهه با ابهام، همه‌ی زبان‌های جاوااسکریپت، پرل و C، از حدس زدن استفاده می‌کنند.

این عبارت در پایتون یک TypeError (خطایی که ساکت نیست) به وجود می‌آورد. یافتن یک «تایپ اِرور» غیر معمول است: این خطا کل برنامه یا حداقل کار فعلی در حال انجام را خاتمه میدهد( به عنوان مثال در اکثر فریمورک‌های تحت وب، بررسی درخواست های فعلی را خاتمه می‌دهد).

پایتون از حدس زدن پاسخ ۱ +"۱" خودداری می‌کند. برنامه‌نویس باید با قصدی مشخص کدنویسی کند: یا 1+int("1")، که حاصلش می‌شود 2، یا "str(1)+"1 که حاصلی برابر با "11" دارد؛ یا از عبارت "1"[1:] استفاده کند، که نتیجه‌ای برابر با رشته ای خالی دارد.این امتناع از حدس زدن توسط پایتون، برنامه‌ها قابل پیش‌بینی تر می‌کند.  

برای انجام یک کار باید یک راه واضح - ترجیحاً فقط و فقط یک راه - وجود داشته باشد.

البته پیش‌بینی کردن یه سوی دیگه هم دارد. با توجه یه وظیفه‌ی محول شده به شما، آیا میتوانید تکه کدی که برای دستیابی به نتیجه‌ی مورد نظر باید نوشته شود را حدس بزنید؟ یقیناً امکان ندارد حدسی دقیق و بی نقص بزنید. در هر حال برنامه‌نویسی کاری خلاقانه است.

با این حال هیچ دلیلی برای ارائه‌ی راه‌حل های متعدد و اضافه برای رسیدن به همان نتیجه وجود ندارد. مفهومی وجود دارد که طبق آن برخی راه‌حل ها 'بهتر' یا 'بیشتر پایتون وار' هستند.

قسمتی از ارزشی که توسط زیبایی شناسی پایتون‌وار آشکار می‌شود، این بوده که داشتن بحث‌هایی سالم درباره‌ی اینکه کدام راه‌حل بهتر است، بلامانع است. حتی مشکلی ندارد که با راه‌حلی مخالف باشید ولی به ادامه‌ی برنامه‌نویسی بپردازید. حتی موافقت کردن با مخالفت در جهت ایجاد توازن بلامانع است. اما در زیر تمام این مسائل، باید احساسی وجود داشته باشد که سرانجام راه‌حل مناسب پدیدار میگردد. باید این امیدواری وجود داشته باشد که ما می‌توانیم با توافق بر سر بهترین راه برای رسیدن به هدفی، سرانجام در سایه‌ی توازن حقیقی زندگی کنیم.

گرچه ممکن است در ابتدا آن راه چندان واضح نباشد (مگر اینکه هلندی باشید).

این اخطاری جدیست: اغلب، در ابتدا مشخص نیست بهترین راه برای دستیابی به یک هدف چیست. ایده‌ها در حال گسترش هستند. پایتون در حال توسعه است. بهترین راه برای خواندن یک فایل به صورت قطعه به قطعه این است که منتظر پایتون نسخه‌ی ۳.۸ و استفاده از عملگر warlus بمانیم.

'یک راه واحد به عنوان بهترین راه‌ برای انجام' این وظیفه‌ی معمولی، خواندن قطعه به قطعه‌ی یک فایل، در طی ۳۰ سال عمر پایتون، وجود نداشت.  

هنگامی که در سال ۱۹۹۸ شروع به استفاده از پایتون با نسخه‌ی ۱.۵.۲ کردم، چیزی به عنوان «بهترین راه» برای خواندن خط به خط یک فایل وجود نداشت. یرای سالهای طولانی بهترین راه برای فهمیدن اینکه آیا یک دیکشنری دارای کلید است، استفاده از .haskey بود، تا وقتی که استفاده از عملگر in به یهترین روش بدل شد.

تنها با درک این نکته است که بعضی مواقع یافتن یک (و تنها)  راه برای رسیدن به یک هدف، میتواند ۳۰ سال آزمون و خطای روش‌های مختلفی که پایتون میتواند دائما از آنها برای رسیدن به آن راه‌حل‌ها استفاده کند، را بطلبد. این نگاه به تاریخ، جایی که ۳۰ سال زمان قابل قبولی برای انجام یک کار است، اغلب برای آمریکایی ها که کشورشان فقط کمی بیشتر از ۲۰۰ سال قدمت دارد، بیگانه است.

هلندی ها، خواه خالق پایتون یعنی گیدو ون روسوم باشد یا دانشمند مشهور علوم کامپیوتر ادزگر د.دایکسترا، با توجه به این بخش از محیط پایتون، جهان‌بینی متفاوتی دارند. درک خاص اروپایی‌ها از زمان باعث ارزشمند پنداشتن بیشتر آن می‌گردد.