ویژگی های جدید و جالب پایتون ۳.۸ – راهنمای کاربردی

جدیدترین نسخه پایتون یعنی پایتون 3.8 در 14 اکتبر 2019 (22 مهر 1398) منتشر شده است. اینک می‌توانیم از امکانات جدید آن استفاده کرده و از مزیت جدیدترین بهبودها بهره‌مند شویم. مستندات پایتون (+) مرور مناسبی در مورد ویژگی‌های جدید این نسخه داشته است. با این حال در این مقاله قصد داریم بررسی عمیق‌تری در مورد برخی از ویژگی های جدید و جالب پایتون 3.8 داشته باشیم و شیوه بهره‌گیری از مزیت‌های نسخه 3.8 را توضیح دهیم.

در این مقاله با مطلب زیر آشنا خواهیم شد:

• استفاده از «عبارت‌ انتسابی» برای ساده‌سازی برخی سازه‌های کد.
• الزام آرگومان‌های «صرفاً موقعیتی» (positional-only) در تابع‌های سفارشی.
• تعیین دقیق‌تر «سرنخ نوع» (type hint).
• استفاده از f-رشته‌ها برای دیباگ ساده‌تر.

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

عبارت انتسابی

بزرگ‌ترین تغییر در نسخه 3.8 پایتون معرفی «عبارت انتسابی» (Assignment Expression) بوده است. این عبارت‌ها با استفاده از نمادگذاری جدید =: نوشته می‌شوند. این عملگر غالباً به نام عملگر «گراز دریایی» (Walrus) خوانده می‌شود، چون شبیه چشم‌ها و عاج‌های این حیوان است.

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

در پایتون 3.8 امکان ترکیب این دو عبارت در یک عبارت واحد و استفاده از عملگر گراز دریایی فراهم شده است:

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

یک الگویی که برخی از نقاط قوت عملگر گراز دریایی را نشان می‌دهد، حلقه‌های While هستند که باید یک متغیر را مقداردهی کرده و به‌روزرسانی کنند. برای نمونه کد زیر از کاربر می‌خواهد تا زمانی که عبارت quit را وارد نکرده است، ورودی‌هایی ارائه کند:

این کد چندان بهینه نیست. گزاره ()input تکرار می‌شود و به هر حال باید پیش از تقاضا از کاربر برای وارد کردن مقدار current، آن را به list اضافه کنید. یک راه‌حل بهتر این است که یک حلقه نامتناهی While تنظیم کنید و از کاربر بخواهید که با استفاده از break حلقه را متوقف کند:

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

بدین ترتیب تست به خط while بازمی‌گردد و این همان جایی است که باید باشد. با این حال، چند اتفاق دیگر نیز در این خط رخ می‌دهند، از این رو برای خواندن آن با اندکی دشواری مواجه می‌شویم. تلاش کنید در مورد مواقعی که استفاده از عملگر گراز دریایی موجب بهبود خوانایی کدتان می‌شود تفکر کنید. در این صفحه (+) همه جزییات عبارت انتسابی شامل برخی از استدلال‌ها برای معرفی آن‌ها در این زبان و همچنین چندین نمونه از شیوه استفاده از این عملگر ارائه شده است.

آرگومان‌های «صرفاً موقعیتی»

در پایتون می‌توان از تابع داخلی ()float برای تبدیل رشته‌های متنی و اعداد به اشیای float بهره گرفت. به مثال زیر توجه کنید:

به امضای متد ()float با دقت نگاه کنید. به کاراکتر / پس از پارامتر توجه کنید. معنای آن این است که وقتی یکی از پارامترهای ()float، به نام x باشد، مجاز به استفاده از نام آن نیستید:

هنگامی که از ()float استفاده می‌کنید، تنها مجاز به تعیین آرگومان‌ها بر اساس موقعیتشان هستید و نه برحسب کلیدواژه. تا پیش از پایتون 3.8، استفاده از چنین آرگومان‌های «صرفاً موقعیتی» تنها در تابع‌های داخلی ممکن بود. در آن زمان هیچ روش آسانی برای تعیین این که آرگومان‌ها باید در تابع‌های سفارشی نیز صرفاً موقعیتی باشند، وجود نداشت:

شبیه‌سازی آرگومان‌های صرفاً موقعیتی با استفاده از args* ممکن است، اما انعطاف‌پذیری کمی دارد، خوانایی آن پایین است و ما را ملزم به پیاده‌سازی یک تحلیل آرگومان سفارشی می‌کند. در پایتون 3.8 می‌توان از کاراکتر ممیز (/) برای نشان دادن این که همه آرگومان‌های پیش از آن باید برحسب موقعیت تعیین شوند، بهره گرفت. بدین ترتیب می‌توانید ()incr را طوری بازنویسی کنید که آرگومان‌های موقعیتی بپذیرد:

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

در کد فوق می‌بینیم که کاراکتر ممیز در ()greet بین name و greeting قرار گرفته است. معنی آن این است که name یک آرگومان صرفاً موقعیتی است در حالی که greeting یک آرگومان معمولی است که می‌تواند برحسب موقعیت یا کلیدواژه تحلیل شود. در نگاه نخست، آرگومان‌های صرفاً موقعیتی تا حدودی محدودکننده به نظر می‌رسند و با شعار پایتون مبنی بر اهمیت خوانایی کد در تضاد هستند. احتمالاً متوجه خواهید شد که موارد چندانی وجود ندارند که استفاده از آرگومان‌های صرفاً موقعیتی موجب بهبود کد شود.

با این حال آرگومان‌های صرفاً موقعیتی در شرایط صحیح می‌توانند نوعی انعطاف‌پذیری در اختیار ما قرار دهند تا بتوانیم تابع‌های خودمان را طراحی کنیم. آرگومان‌های صرفاً موقعیتی در وهله نخست در مواردی کاربرد دارند که آرگومان‌هایی با ترتیب طبیعی داریم، اما تعیین نام‌های خوب و گویا برای آن‌ها دشوار است. مزیت احتمالی دیگر استفاده از آرگومان‌های صرفاً موقعیتی این است که می‌توان تابع‌های سفارشی را آسان‌تر «بازسازی» (Refactor) کرد. به طور خاص می‌توانید نام پارامترهای خود را بدون نگرانی از این که کدهای دیگر وابسته به آن نام‌ها چه بر سرشان می‌آید، تغییر دهید.

آرگومان‌های صرفاً موقعیتی به خوبی با آرگومان‌های «صرفاً کلیدواژه‌ای» (keyword-only) تکمیل می‌شوند. در پایتون نسخه 3 می‌توانید آرگومان‌های صرفاً کلیدواژه‌ای را با استفاده از کاراکتر ستاره (*) تعیین کنید. هر آرگومانی پس از ستاره باید با استفاده از یک کلیدواژه تعیین شده باشد:

Celsius یک آرگومان صرفاً کلیدواژه‌ای است و از این رو در صورتی که تلاش کنید آن را برحسب موقعیت و بدون کلیدواژه تعیین کنید، پایتون خطایی صادر می‌کند. امکان ترکیب آرگومان‌های صرفاً موقعیتی با آرگومان‌های معمولی و صرفاً کلیدواژه‌ای وجود دارد. به این منظور باید آن‌ها را با ترتیبی که در جمله قبلی ذکر شد بیاورید و با کاراکترهای / و * از هم جدا کنید. در مثال زیر text یک آرگومان صرفاً موقعیتی است، border یک آرگومان معمولی با مقدار پیش‌فرض و width یک آرگومان صرفاً کلیدواژه‌ای با یک مقدار پیش‌فرض است:

از آنجا که text، صرفاً موقعیتی است، نمی‌توانید از کلیدواژه text استفاده کنید:

از سوی دیگر border می‌تواند هم با کلیدواژه و هم بدون آن تعیین شود:

در نهایت width باید صرفاً با استفاده از کلیدواژه تعیین شود:

برای مطالعه بیشتر در خصوص آرگومان‌های صرفاً موقعیتی به این صفحه (+) مراجعه کنید.

انواع دقیق دیگر

سیستم نوع‌بندی داده‌ها در پایتون هم اینک به بلوغ کامل رسیده است. با این حال در پایتون 3.8 ویژگی‌های جدیدی به typing اضافه شده تا امکان نوع‌بندی دقیق‌تری فراهم شود:

• انواع Literal
• دیکشنری‌های نوع‌دار
• شی‌ءهای Final
• پروتکل‌ها

پایتون از «سرنخ نوع» (type hints) به شیوه اختیاری پشتیبانی می‌کند که به طور معمول به صورت «حاشیه‌نویسی» (annotations) روی کد می‌آید:

در این مثال بیان می‌کنیم که number باید به صورت یک مقدار float باشد و تابع ()double باید یک مقدار float بازگشت دهد. با این حال پایتون این حاشیه‌نویسی‌ها را به عنوان سرنخ تلقی می‌کند. آن‌ها در زمان اجرا الزامی پیش نمی‌آورند:

بدین ترتیب ()double به خوبی I'm not a float را به عنوان یک آرگومان می‌پذیرد، هر چند می‌دانیم که float نیست. کتابخانه‌هایی وجود دارند که می‌توانند از نوع‌ها در زمان اجرا استفاده کنند، اما کاربرد عمده‌ای در سیستم نوع‌بندی پایتون ندارند.

از سوی دیگر سرنخ‌های پایتون به ما امکان می‌دهند که «بررسی‌کننده نوع» (type checker) استاتیک داشته باشیم و نوع‌ها را در کد پایتون بدون نیاز به اجرای عملی اسکریپت‌ها مورد بررسی قرار دهیم. این امکان شبیه به دام انداختن خطاهای نوع از سوی کامپایلر در زبان‌های دیگر مانند جاوا، Rust و Crystal است. به علاوه سرنخ‌های نوع به عنوان مستنداتی برای کد عمل می‌کنند که خواندن آن را ساده‌تر می‌سازند و به بهبود ویژگی تکمیل خودکار کد در IDE کمک می‌کنند. چندین نوع بررسی‌کننده نوع استاتیک از قبیل Pyright, Pytype و Pyre وجود دارند. ما در این مقاله از Mypy استفاده می‌کنیم. Mypy را می‌توانید با استفاده از pip به صورت زیر نصب کنید:

$ python -m pip install mypy

در واقع به یک معنی Mypy پیاده‌سازی مرجع یک بررسی‌کننده نوع در پایتون محسوب می‌شود و از سوی Dropbox توسعه یافته است. خالق پایتون «گیدو فان روسوم» (Guido van Rossum) نیز عضوی از تیم Mypy است. برای کسب اطلاعات بیشتر در مورد سرنخ نوع در پایتون به این صفحه (+) مراجعه کنید.

چهار نوع جدید PEP در مورد بررسی نوع وجود دارد که پذیرش یافته و در پایتون 3.8 وارد شده است. در ادامه مثال‌های کوچکی از هر کدام می‌بینید. PEP 586 نوع Literal را معرفی می‌کند. Literal کمی خاص است، زیرا یک یا چند مقدار خاص را نشان می‌دهد. یکی از کاربردهای Literal این است که می‌توانیم در زمان استفاده از آرگومان‌های رشته‌ای برای توصیف یک رفتار خاص، نوع‌ها را به صورت دقیقی اضافه کنیم. به مثال زیر توجه کنید:

این برنامه یک بررسی‌کننده نوع استاتیک ارسال خواهد کرد، هر چند up یک جهت نامعتبر محسوب می‌شود. بررسی‌کننده نوع تنها بررسی می‌کند که آیا up یک رشته است یا نه. در این حالت، اگر بخواهیم دقیق‌تر عمل کرده و اعلام کنیم که جهت باید یکی از رشته‌های لفظی horizontal یا vertical باشد، می‌توانیم از Literal به صورت زیر بهره بگیریم:

با اعلام مقادیر مجاز برای direction به بررسی‌کننده نوع، اینک می‌توانیم در مورد بروز خطا هشداری صادر کنیم:

این ساختار ابتدایی به صورت Literal[<literal>] است. برای نمونه Literal[38] نماینده مقدار لفظی 38 است. امکان افشای یکی از چندین مقدار لفظی با استفاده از Union وجود دارد:

Union[Literal["horizontal"], Literal["vertical"]]

از آنجا که این کاربرد نسبتاً رایجی است، می‌توانید (و احتمالاً بهتر است) از نمادگذاری ساده‌تر Literal["horizontal", "vertical"] به جای آن بهره بگیرید. ما قبلاً از حالت دوم برای افزودن نوع به ()draw_line استفاده کرده‌ایم. اگر به دقت به خروجی Mypy فوق نگاه کنید، می‌بینید که نمادگذاری ساده‌تر به صورت داخلی به نمادگذاری Union ترجمه شده است. مواردی وجود دارند که نوع مقدار بازگشتی یک تابع به آرگومان‌های ورودی وابسته است. یک نمونه از آن ()open است که می‌تواند بسته به مقدار mode یک رشته متنی یا یک آرایه بایتی بازگشت دهد. انجام این کار از طریق Overloading (+) میسر است. در مثال زیر چارچوب یک ماشین حساب را می‌بینید که می‌تواند بسته به این که اعداد معمولی (38) و یا اعداد رومی (XXXVIII) وارد شده باشد، پاسخ متفاوتی بازگشت دهد:

این کد سرنخ‌های نوع صحیحی دارد. نتیجه ()add به صورت str و یا int خواهد بود. با این حال، در اغلب موارد این کد با یک نوع لفظی True یا False به عنوان مقدار to_roman فراخوانی می‌شود که در این حالت علاقه‌مند هستیم بررسی‌کننده نوع استنباط کند مقدار بازگشتی str و یا int خواهد بود. این کار با استفاده همزمان از Literal و overload@ میسر است:

در کد فوق امضای overload@ که اضافه شده است به بررسی‌کننده نوع کمک می‌کند که بسته به مقادیر لفظی to_roman نوع خروجی را به صورت int یا str استنباط کند. توجه داشته باشید که (...) ellipses بخشی لفظی از کد محسوب می‌شود. این بخش در امضای Overload شده به جای بدنه تابع آمده است.

PEP 591 نوع Final را به عنوان مکملی برای Literal معرفی کرده است. این qualifier تعیین می‌کند که یک متغیر یا خصوصی امکان انتساب مجدد، تغییر تعریف یا Override شدن را دارد یا نه. در ادامه یک خطای نوع‌بندی را مشاهده می‌کنید:

Mypy خط ID += 1 را هایلایت کرده و به خطای زیر اشاره می‌کند:

you Cannot assign to final name "ID"

بدین ترتیب می‌توانیم مطمئن باشیم که مقدار ثابت‌ها در کد هرگز تغییر نمی‌یابد. به علاوه یک دکوراتور final@ نیز وجود دارد که می‌تواند روی کلاس‌ها و متدها اعمال شود و کلاس‌های دارای final@ نمی‌توانند کلاس‌های فرعی ایجاد کند. همچنین متدهای دارای final@ نمی‌توانند از سوی کلاس فرعی Override شوند.

Mypy این مثال را با پیام خطایی به صورت زیر علامت‌گذاری کرده است:

Cannot inherit from final class "Base".

برای یادگیری موارد بیشتر در خصوص دکوراتور final@ به این لینک (+) مراجعه کنید. سومین PEP که امکان تعیین سرنخ‌های دقیق‌تر نوع را فراهم ساخته PEP 589 است. این PEP TypedDict را معرفی می‌کند. TypedDict می‌تواند برای تعیین نوع برای کلیدها و مقادیر یک دیکشنری با استفاده از نمادگذاری مشابه NamedTuple مورد استفاده قرار گیرد.

به طور سنتی دیکشنری‌ها با استفاده از dict حاشیه‌نویسی می‌شوند. مشکل این است که این dict تنها امکان داشتن یک نوع برای کلید و یک نوع را برای مقادیر فراهم می‌سازد. این وضعیت معمولاً منجر به برخی حاشیه‌نویسی‌ها مانند Dict[str, Any] می‌شود. به عنوان مثال، یک دیکشنری را تصور بکنید که اطلاعاتی در مورد نسخه‌های پایتون ثبت می‌کند:

py38 = {"version": "3.8", "release_year": 2019}

مقدار متناظر با version یک رشته است، در حالی که مقدار release_year یک عدد صحیح است. این وضعیت با استفاده از دیکشنری به صورت دقیقی قابل بازنمایی نیست. با استفاده از TypedDict که در پایتون 3.8 معرفی شده است می‌توان به صورت زیر عمل کرد:

سپس بررسی‌کننده‌های نوع می‌توانند استنباط کنند که py38["version"] نوع str دارد، در حالی که py38["release_year"] یک int است. در زمان اجرا یک py38["release_year"] همان dict معمولی است و سرنخ‌های نوع به طور معمول نادیده گرفته می‌شوند. همچنین می‌توانید از TypedDict صرفاً به عنوان یک حاشیه‌نویسی استفاده کنید:

py38: PythonVersion = {"version": "3.8", "release_year": 2019}

Mypy این امکان را فراهم می‌سازد که بدانیم کدام یک از مقادیر نوع نادرستی دارند. همچنین اگر از یک کلید استفاده کنید که اعلان نشده باشد، به شما هشداری داده می‌شود. برای مشاهده مثال‌های بیشتر به صفحه PEP 589 (+) مراجعه کنید.

Mypy مدتی است که از «پروتکل‌ها» (Protocols) پشتیبانی می‌کند. با این حال پذیرش رسمی آن در تاریخ می 2019 (اردیبهشت 1398) بوده است. پروتکل‌ها روشی برای صورت‌بندی پشتیبانی پایتون از «نوع‌بندی اردکی» (duck typing) محسوب می‌شوند:

وقتی می‌بینیم که پرنده‌ای شبیه اردک راه می‌رود، شبیه اردک شنا می‌کند و صدایی شبیه اردک دارد، این پرنده را اردک می‌نامیم. منبع (+)

برای نمونه نوع‌بندی اردکی به ما امکان می‌دهد که یک ‎.name را روی هر شیئی که دارای خصوصیت ‎.name است بخوانیم و عملاً اهمیتی به نوع شیء ندهیم. پشتیبانی از این وضعیت از سوی سیستم نوع‌بندی، غیرمنطقی به نظر می‌رسد. با این حال از طریق «نوع‌بندی فرعی ساختاری» (structural subtyping) امکان درک معنی نوع‌بندی اردکی وجود دارد. برای نمونه می‌توان یک پروتکل به نام Named تعریف کرد که اشیای با خصوصیت name. را شناسایی کند:

در این کد، ()great تا زمانی که یک شیء خصوصیت ‎.name را تعریف کرده باشد، آن را می‌پذیرد. برای کسب اطلاعات بیشتر در مورد PEP 544 به صفحه مستندات Mypy (+) مراجعه کنید.

دیباگ ساده‌تر با f-رشته‌ها

f-رشته‌ها در پایتون 3.6 معرفی شدند و محبوبیت زیادی کسب کردند. آن‌ها احتمالاً رایج‌ترین دلیل این مسئله‌اند که اغلب کتابخانه‌های پایتون از نسخه 3.6 و بالاتر این زبان پشتیبانی می‌کنند. یک f-رشته در واقع یک لفظ رشته‌ای قالب‌بندی شده است. آن را می‌توان از روی حرف f در ابتدایش شناسایی کرد:

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

در عبارت آخر {math.pi * r * r:.2f} می‌توان از یک «تعیین‌کننده قالب» (Format Specifier) نیز استفاده کرد. تعیین‌کننده‌های قالب با یک کاراکتر دونقطه (:) از عبارت جدا می‌شوند:

برای نمونه 2f. به این معنی است که این ناحیه به صورت یک عدد اعشاری با 2 رقم اعشار قالب‌بندی شده است. تعیین‌کننده‌های قالب همانند ()format. عمل می‌کنند. برای کسب اطلاعات بیشتر در مورد لیست کامل این تعیین‌کننده‌های قالب به این صفحه (+) مراجعه کنید. در پایتون 3.8 می‌توانید از عبارت انتسابی درون f-رشته‌ها بهره بگیرید. کافی است مطمئن شوید که عبارت انتسابی درون پرانتز قرار گرفته است:

با این حال، خبر مهم مرتبط با f-رشته‌ها در پایتون 3.8 امکان دیباگ تعیین‌کننده‌ها است. اکنون می‌توانید یک علامت مساوی (=) در ابتدای یک عبارت اضافه کنید و بدین ترتیب هم عبارت و مقدار آن را پرینت کنید:

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

همچنین می‌توانید کاراکترهای فاصله پیرامون علامت مساوی (=) اضافه کنید و از تعیین‌کننده‌های قالب به صورت معمول بهره بگیرید:

در کد فوق، تعیین‌کننده قالب >10 بیان می‌کند که name باید در یک رشته با طول 10 کاراکتر در انتهای آن قرار گیرد. این وضعیت در مورد عبارت‌های پیچیده‌تر نیز کار می‌کند:

شورای مدیریت پایتون

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

• بِری وُرساو (Barry Warsaw)
• برِت کانون (Brett Cannon)
• کارول ویلینگ (Carol Willing)
• گیدو فان روسوم (Guido van Rossum)
• نیک کولِن (Nick Coghlan)

مسیر منتهی به این مدل مدیریت پایتون یک مطالعه جالب در خصوص خودسازمان‌دهی محسوب می‌شود. گیدو فان روسوم پایتون را در اوایل دهه 1990 ساخت و خود را «دیکتاتور خیرخواه جاویدان» (Benevolent Dictator for Life) به اختصار BDFL نامید. در طی سال‌ها به مرور تصمیم‌های زیادی در مورد پایتون از طریق سیستم «پیشنهادهای بهبود پایتون» (Python Enhancement Proposals) به اختصار PEP اتخاذ شده است. اما گیدو هنوز به طور رسمی در مورد همه قابلیت‌های جدید زبان پایتون حرف آخر را می‌زند.

گیدو پس از یک بحث طولانی و مطول در مورد عبارت‌های انتسابی، در جولای 2018 (مرداد 1397) اعلام کرد که قصد دارد از نقش خود به عنوان BDFL بازنشسته شود. او عامدانه از تعیین جانشین خودداری کرد و از تیم اصلی توسعه‌دهندگان تقاضا نمود که تعیین کنند پایتون در ادامه چگونه باید مدیریت شود.

خوشبختانه فرایند PEP در این زمان به خوبی تثبیت شده بود و از این رو روند طبیعی این بود که از PEP-ها برای بحث و تصمیم‌گیری در مورد مدل حکمرانی جدید پایتون استفاده شود. در طی پاییز سال 2018 (1397) چندین مدل پیشنهاد شدند که شامل انتخاب یک BDFL جدید بود. عنوان آن به «مدیر تصمیم‌گیری در مورد تصمیم‌های مؤثر بر امپراتوری» (Gracious Umpire Influencing Decisions Officer) به اختصار GUIDO تغییر می‌یافت. همچنین پیشنهاد حرکت به سمت مدل جامعه‌ای بر مبنای اجماع و رأی‌دهی بدون مدیریت متمرکز مطرح شد. در دسامبر سال 2019 (آذر 1397) مدل «شورای مدیریتی» (Steering Council) پس از رأی‌گیری در میان توسعه‌دهندگان تیم مرکزی انتخاب شد.

شورای مدیریتی شامل پنج عضو از جامعه پایتون است که در تصویر فوق مشخص شده‌اند. این اعضا پس از انتشار هر نسخه عمده پایتون (Major Release) انتخاب می‌شوند. به بیان دیگر پس از انتشار نسخه 3.8 پایتون یک انتخابات برگزار خواهد شد.

با این که این یک انتخابات باز است، اما انتظار می‌رود که اگر نه همه اعضای کنونی، دست‌کم اغلب اعضای آن مجدداً انتخاب شوند. شورای مدیریت دارای اختیارات در سطح هیئت‌مدیره برای اتخاذ تصمیم در مورد زبان پایتون است، اما باید تلاش کند از این اختیارات در حد امکان بهره نگیرد.

قابلیت‌های جالب دیگر

تا به اینجا با عناوین قابلیت‌های جدید پایتون 3.8 آشنا شدیم. با این حال تغییرهای زیاد دیگری وجود دارند که آن‌ها نیز جالب توجه هستند. در این بخش برخی از آن‌ها را با هم مرور می‌کنیم.

فیلم آموزش برنامه نویسی پایتون + مثال های عملی در Python در فرادرس

کلیک کنید

importlib.metadata

یک ماژول جدید در کتابخانه استاندارد پایتون 3.8 به نام importlib.metadata اضافه شده است. از طریق این ماژول می‌توان به اطلاعاتی در مورد نسخه نصبی پایتون دسترسی یافت. این ماژول به همراه ماژول همراه خود importlib.resources کارکرد ماژول قدیمی‌تر pkg_resources را بهبود می‌بخشد. به عنوان مثال می‌توانید در مورد pip اطلاعاتی به دست آورید:

نسخه نصب شده کنونی pip به صورت 19.2.3 است. ماژول ()metadata امکان دسترسی به اغلب اطلاعتی که در PyPI می‌بینید را فراهم ساخته است. برای نمونه می‌توان دید که این نسخه از pip نیازمند نسخه 2.7 پایتون و یا نسخه 3.5 و بالاتر از پایتون است. با استفاده از ()files می‌توان به لیستی از همه فایل‌هایی که پکیج‌های pip را تشکیل می‌دهند دسترسی داشت. در این مورد، تقریباً 700 فایل وجود دارد. ()files لیستی از اشیای Path بازگشت می‌دهد. این لیست یک روش آسان برای بررسی کد منبع پکیج با استفاده از ()read_text در اختیار ما قرار می‌دهد. مثال زیر init__.py__ را از پکیج realpython-reader نشان می‌دهد:

همچنین می‌توانید به وابستگی‌های پکیج نیز دسترسی داشته باشید:

متد ()requires وابستگی‌های پکیج را لیست می‌کند. چنان که می‌بینید realpython-reader برای نمونه از feedparser در پس‌زمینه برای خواندن و تحلیل فید مقالات بهره می‌گیرد. یک در پشتی importlib.metadata نیز روی PyPI وجود دارد که روی نسخه‌های قبلی پایتون کار می‌کند. آن را می‌توانید با استفاده از pip نصب کنید:

$ python -m pip install importlib-metadata

با استفاده از کد زیر می‌توانید تعیین کنید که در صوت بروز مشکل از PyPI backport استفاده شود:

برای کسب اطلاعت بیشتر به مستندات (+) importlib.metadata مراجعه کنید.

تابع‌های جدید و بهبود یافته math و statistics

پایتون 3.8 بهبودهای زیادی در مورد پکیج کتابخانه استاندارد و ماژول‌ها به همراه داشته است. math در کتابخانه استاندارد چند تابع جدید دارد. ()math.prod به طرزی مشابه ()sum داخلی کار می‌کند، اما برای multiplicative product مورد استفاده قرار می‌گیرد:

این دو گزاره معادل هم هستند. استفاده از ()prod در مواردی که فاکتورها از قبل در یک «تکرارشونده» (iterable) ذخیره شده باشند، آسان‌تر خواهد بود. تابع جدید دیگر ()math.isqrt است. این تابع برای یافتن بخش صحیح ریشه‌های دوم (جذر) استفاده می‌شود:

ریشه دوم 9 برابر با 3 است. چنان که می‌بینید ()isqrt بخش صحیح عدد را بازگشت می‌دهد، در حالی که ()math.sqrt همواره یک عدد float بازمی‌گرداند. ریشه دوم 15 برابر با 3.9 است. توجه کنید که ()isqrt پاسخ را به صورت عدد صحیح کوچک‌تر یعنی 3 درمی‌آورد.

در نهایت می‌توانید در کتابخانه استاندارد به روش آسان‌تری با نقاط n-بعدی و بردارها کار کنید. بدین ترتیب می‌توان مسافت بین دونقطه را با استفاده از ()math.dist یافت. طول بردار را نیز می‌توان با ()math.hypot پیدا کرد:

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

ماژول statistics نیز چند تابع جدید دارد:

• ()statistics.fmean میانگین اعداد float را محاسبه می‌کند.
• ()statistics.geometric_mean میانگین هندسی اعداد float را محاسبه می‌کند.
• ()statistics.multimode فراوانی مقادیر را در یک دنباله محاسبه می‌کند.
• ()statistics.quantiles نقاط برش را در زمان تقسیم داده‌ها به n بازه پیوسته با احتمال یکسان محاسبه می‌کند.

در مثال زیر کاربرد عملی تابع‌ها را مشاهده می‌کنید:

در پایتون 3.8 یک کلاس جدید به نام statistics.NormalDist وجود دارد که کار با توزیع نرمال گائوسی را آسان‌تر ساخته است. برای دیدن مثالی از کاربرد NormalDist می‌توانید سرعت ()statistics.fmean و روش سنتی یعنی ()statistics.mean را مقایسه کنید:

در این مثال از timeit برای اندازه‌گیری زمان اجرای ()mean و ()fmean استفاده شده است. برای دریافت نتایج قابل اطمینان باید اجازه دهید timeit هر تابع را 100 بار اجرا کند و 30 نمونه زمانی این چنینی برای هر تابع به دست آورد. بر اساس این نمونه‌ها می‌توانید دو شیء NormalDist ایجاد کنید. توجه داشته باشید که اگر کد را خودتان اجرا کنید، ممکن است تا یک دقیقه زمان صرف گرداوری نمونه‌های زمانی مختلف شود.

NormalDist خصوصیت‌ها و متدهای ساده زیادی دارد. برای دیدن لیست همه آن‌ها به مستندات (+) مراجعه کنید. با بررسی ‎.mean و ‎.stdev می‌بینیم که ()statistics.mean در طی زمان 0.826 به علاوه منهای 0.078 ثانیه اجرا می‌شود، در حالی که متد جدید ()statistics.fmean برای اجرا به 0.0105  به علاوه منهای  0.0009 ثانیه زمان نیاز دارد. به بیان دیگر ()fmean روی این داده‌ها 80 بار سریع‌تر بوده است.

هشدار در مورد ساختار خطرناک

پایتون قابلیتی به صورت SyntaxWarning (+) دارد که در مورد ساختارهای مشکوک که عموماً یک SyntaxError نیستند، هشدار می‌دهد. پایتون 3.8 چند هشدار جدید اضافه کرده است که در زمان کدنویسی و دیباگ به شما کمک می‌کنند.

اختلاف بین is و == می‌تواند سردرگم‌کننده باشد. دومی برابر بودن مقدار را بررسی می‌کند، در حالی که is تنها زمانی True است که اشیا یکسان باشند. پایتون 3.8 تلاش می‌کند در خصوص مواردی که باید از == به جای is استفاده کنید، به شما هشدار بدهد:

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

این هشدار در حال حاضر مشخص می‌کند که کامای فراموش‌شده دلیل اصلی بروز خطا بوده است.

بهینه‌سازی

چندین بهینه‌سازی در پایتون 3.8 صورت گرفته است. برخی از آن‌ها موجب اجرای سریع‌تر کد می‌شوند. برخی دیگر مصرف حافظه را کاهش می‌دهند. برای نمونه اکنون گشتن در یک namedtuple به میزان چشمگیری سریع‌تر از پایتون 3.7 شده است:

چنان که می‌بینید گشتن در ‎.twitter به دنبال namedtuple اکنون در پایتون 3.8 به میزان 30 تا 40% سریع‌تر شده است. لیست‌ها زمانی که از تکرارشونده‌هایی با طول مشخص مقداردهی شوند، موجب صرفه‌جویی در مصرف حافظه هم می‌شوند. به مثال زیر توجه کنید:

در این حالت، لیست از 11% حافظه کمتری در پایتون 3.8 در مقایسه با نسخه 3.7 استفاده می‌کند. بهینه‌سازی‌های دیگری نیز در نسخه 3.8 به صورت بهبود عملکرد subprocess، کپی کردن سریع‌تر فایل با shutil، بهبود عملکرد پیش‌فرض در pickle و عملیات سریع‌تر عملگر itemgetter. مشاهده می‌شود.

چرا باید پایتون را به نسخه 3.8 ارتقا دهیم؟

ابتدا پاسخ ساده‌تر را به این سؤال ارائه می‌کنیم. اگر می‌خواهید قابلیت‌های جدیدی که در این مقاله مورد بررسی قرار دادیم را در عمل مشاهده کنید، باید از پایتون 3.8 استفاده کنید. ابزارهایی مانند pyenv و Anaconda امکان نصب چندین نسخه از پایتون را در کنار هم به سادگی فراهم ساخته‌اند. به طور جایگزین می‌توانید کانتینر داکر رسمی پایتون 3.8 (+) را اجرا کنید. استفاده از پایتون 3.8 هیچ مشکلی برای شما ایجاد نخواهد کرد.

اما سؤال‌های پیچیده‌تر این است که آیا باید محیط پروداکشن را نیز به پایتون 3.8 ارتقا دهیم؟ آیا باید پروژه خود را به نسخه 3.8 وابسته کنیم تا از مزیت قابلیت‌های جدید بهره‌مند شویم؟

اجرای کد پایتون 3.7 در نسخه 3.8 نباید مشکل چندانی ایجاد کند. از این رو ارتقای محیط برای اجرای پایتون 3.8 کاملاً امن است و می‌توانید از مزیت بهینه‌سازی‌های صورت گرفته در نسخه جدید بهره‌مند شوید. نسخه‌های بتای مختلف پایتون 3.8 ماه‌ها است که عرضه شده‌اند و به همین جهت به احتمال زیاد اغلب باگ‌ها هم اینک رفع شده‌اند. با این حال اگر می‌خواهید محافظه‌کارانه عمل کنید، بهتر است تا زمان ارائه نسخه maintenance یعنی پایتون 3.8.1 صبر کنید.

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

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه‌نویسی پایتون Python
• مجموعه آموزش‌های برنامه‌‌نویسی
• گنجینه آموزش‌های برنامه‌نویسی پایتون (Python)
• زبان برنامه نویسی پایتون (Python) — از صفر تا صد
• تحلیل شبکه‌های اجتماعی در پایتون — راهنمای کاربردی

==