#سوال ✨
کار کدام تابع زودتر به پایان می‌رسد ⁉️

✍️ *ژنرال*

💎 Channel: @DevelopixPython

💠 PEP 749: Deferred Evaluation Of Annotations Using Descriptors

بعد از چند سال حالا PEP 649 به لطف ارائه خوب PEP 749 تایید شده و قراره تحولی رو در annotation ها داشته باشیم.
به این کد دقت کنید:

class A:
    def method(self) -> B: ...

class B: ...

در حالت عادی چون نوع برگشتی method ما B هست و B هم تا اون لحظه تعریف نشده به NameError برخورد میکنیم. این تا حد زیادی تبدیل به یک معضل شده بود تا اینکه اجازه استفاده از literal string ها به عنوان نوعی ارجاع دهنده داده شد که در __annotations__ هم لحاظ میشن. این موضوع حتی فراتر از این حدود هم پیش رفت و با ارائه PEP 563 و امکان استفاده از annotations در __future__، تمام annotation ها هنگام اجرای کد (runtime) تبدیل به string میشن (بدون استثنا، تمام annotation ها).

خب، این واقعا کثیف کاری بود. IDE ها به درستی میتونستند type ها رو تشخیص بدند و مفسر هم دیگه خطای NameError نمیداد:

from __future__ import annotations

class A:
    def method(self) -> B: ...

class B: ...

اما همونطور که گفته شد همه اونها به string تبدیل میشدند و اگر کد زیر خواسته میشد خروجی مطلوب (که خود کلاس B هست) داده نمیشد و در عوض "B" رو میدیدم.

print(A.method.__annotations__)

این یعنی مشکل. چرا؟ چون در صورتی که مقدار local باشه الزاما دیگه به متغیر ها دسترسی نداریم و حتی اگر دسترسی داشته باشیم باید اون رو eval کنیم که کار جالبی نیست.

راه‌حلی درحال اضافه شدن هست. در نسخه 3.14 باز هم از مفهوم lazy evaluation قراره استفاده دیگه‌ای بشه. علت برخورد شما به NameError در کد اول این هست که مفسر بلافاصله میخواد به annotation دسترسی پیدا کنه، اما حالا این کار رو انجام نمیده و فقط زمانی که باید بهشون دسترسی گرفته بشه این کار رو انجام میده که باعث میشه موقع load کردن code شما حتی اگر annotation وجود خارجی هم نداشت باعث مشکل نشه.

این یک تحول نسبتا بزرگ برای زبان پایتون هست، اللخصوص برای نویسندگان کتابخونه ها. ممکنه دیده باشید که به جای SomeType نوشته شده باشه "SomeType" چرا؟ چون به هر دلیلی نویسنده خواسته از NameError فرار کنه. اما حالا نه، لازم نیست quote قرار داده بشه و مستقیما میشه از خودش استفاده کرد.

چه اتفاقی برای annotations در __future__ میوفته؟ در نسخه 3.15 حذف میشه و احتمالا هشدار منسوخ شدن برای استفاده از اون در نسخه 3.14 اضافه خواهد شد.

این موضوع حتی فراتر از این حرف ها هست و ما حتی یک module کاملا جدید رو قراره در stdlib داشته باشیم. همونطور که گفته شده استفاده از inspect برای دسترسی به annotation ها راه خوبی نیست چون واقعا سنگینه. پس حالا annotationlib رو قراره داشته باشیم که ابزاری کاملا مناسب هست و به راحتی قابل استفاده‌ست.

ما تابه‌حال نوع خاصی برای annotation ها نداشتیم (نوع کلی) اما حالا داریم:

‏1. VALUE: همون مقدار پیش‌فرض که تا الان هم داشتیم
‏2. FORWARDREF: در صورت نبود مقدار مشخصی برای اسم به کار برده شده
‏3. STRING: مقدار متنی اونها (کاملا مناسب برای ابزار document کردن)

تنها مورد جدید ForwardRef هست. چه زمانی این نوع دیده میشه؟ زمانی که عملا هیچ چیزی با این name وجود نداشته باشه (قبلا در این شرایط NameError داده میشد) و حالا با این نوع گفته میشه که "این نوع unresolved هست"

این موضوع هیچ تاثیر منفی روی std wrapper هایی مثل classmethod، staticmethod، functools.wraps و موارد دیگه قرار نیست بزاره و همه همگام میشن پس لازم نیست در این مورد نگران باشیم.

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

✍️ *ژنرال*

🏷 #Python, #PEP, #annotations, #typehint, #pep749, #NameError

💎 Channel: @DevelopixPython

💠 PEP 758 – Allow except and except* expressions without parentheses

با قبول PEP 758 حالا syntax جدیدی رو برای ساختار try-except در نسخه 3.14 داریم. این موضوع ساختار های مورد قبول فعلی رو تغییر نمیده و فقط ساختاری جدید رو اضافه میکنه.

ابتدا بهتره یک مرور ساده روی ساختار فعلی except داشته باشیم:

except_block:
    | "except" expression ["as" identifier] ":" block
    | "except" "*" expression ["as" identifier] ":" block

اگر لازم بود که از چند exception استفاده کنیم اونها رو داخل پرانتز قرار میدادیم و با ساختار زیر از اون استفاده میکردیم:

except_block:
    | "except" (expressions) ["as" identifier] ":" block
    | "except" "*" (expressions) ["as" identifier] ":" block

یا به طور دقیق تر:

except_block:
    | "except" "(" expression ("," expression)+ ")" [ "as" identifier ] ":" block
    | "except" "*" "(" expression ("," expression)+ ")" [ "as" identifier ] ":" block

به شکل:

try:
    risky_operation()
except (ValueError, TypeError, RndExcept):
    handle_error()

این PEP چیز بخصوصی رو به همراه نداره، تنها موردی که به این زبان اضافه میکنه اینه که از حالا در صورتی که از کلمه کلیدی as استفاده نشه میتونیم از پرانتز ها صرف‌نظر کنیم. پس حالا ساختار های زیر رو در پایتون ممکنه ببینید:

except_block:
    | 'except' expressions ':' block
    | 'except' '*' expressions ':' block

به طور خلاصه میتونیم بگیم که اگر تا الان کد زیر با SyntaxError برخورد میکرد، حالا در نسخه 3.14 به هیچ مشکلی برخورد نمیکنه و به درستی اجرا میشه:

try:
    risky_operation()
except ValueError, TypeError, RndExcept:
    handle_error()

اما باید توجه داشت که اگر لازم باشه از as و یک identifier استفاده بشه وجود پرانتز ها همچنان الزامی هستند.

دلیل اضافه شدن این امکان عمدتا مرتبط به خوانایی کد و ساده کردن قسمت هاست. استفاده از پرانتز باتوجه به نبود هیچ چیز اضافه دیگه‌ای غیرضروری بنظر میرسید و باتوجه به سایر قسمت ها که اضافه کردن پرانتز در این شرایط رو اختیاری کردند، این تغییر کمک میکنه تا قسمت except از ساختار کلی error handling در پایتون هم مقداری مشابه سایر قسمت ها بشه. به طور خلاصه میتونیم بگیم که اگر از python2 استفاده میکردید و به این شکل خطاها رو مدیریت میکردید، حالا باز هم مجاز به انجام این کار هستید.

✍️ *ژنرال*

🏷 #Python, #PEP, #except, #try, #pep785

💎 Channel: @DevelopixPython

🎯 بررسی پلتفرم‌های اجرای کد پایتون در موبایل

🔵 Android:

🐍 Pydroid 3

✅ مزایا:
⬅️ ساپورت اکثر کتابخانه‌های پایتون
⬅️ دارای ترمینال و محیط گرافیکی GUI
⬅️ نسخه‌ی پرمیوم با قابلیت auto complete
⬅️ اجرای کدها بدون نیاز به اینترنت

❌ معایب:
⬅️ نسخه‌ی پایتون ثابت و غیرقابل ارتقا
⬅️ برخی کتابخانه‌های سنگین در نسخه رایگان کار نمی‌کنند
⬅️ عملکرد کند ادیتور در پروژه‌های بزرگ


🐍 Termux

✅ مزایا:
⬅️ محیط شبیه‌سازی شده لینوکس
⬅️ داشتن shell
⬅️ امکان نصب نسخه دلخواه از پایتون
⬅️ کنترل کامل روی پکیج‌ها و...
⬅️ استفاده از مفسر رسمی پایتون که از طریق بسته‌های apt نصب می‌شود

❌ معایب:
⬅️ فاقد محیط گرافیکی به‌جز Tkinter که از طریق بسته‌های پایتون قابل نصب می‌باشد


⬜️ IOS

🐍 Pyto

✅ مزایا:
⬅️ ساپورت از نسخه‌های پایتون و رابط کاربری
⬅️ امکان نصب بسیاری از کتابخانه‌ها

❌ معایب:
⬅️ اجرای کند
⬅️ عدم ساپورت از برخی کتابخانه‌ها


🐍 Pythonista

✅ مزایا:
⬅️ پشتیبانی از بسیاری از کتابخانه‌ها
⬅️ مناسب برای ساخت اپلیکیشن‌های ساده با رابط کاربری

❌ معایب:
⬅️ نصب کتابخانه‌ها بصورت پیچیده
⬅️ نسخه‌ی پولی


🐍 Google Colab

✅ مزایا:
⬅️ اجرای کد بدون نیاز به نصب نرم‌افزار از طریق Browser
⬅️ اجرای کدها در سرورهای قوی با مفسر پایتون
⬅️ امکان ذخیره نوت‌بوک‌ها و اشتراک‌گذاری آن‌ها

❌ معایب:
⬅️ نیاز به اینترنت
⬅️ اجرای موقتی و...

🔖 #Python, #پایتون, #android, #ios, #pydroid, #pyto

👤 𝐏𝐫𝐨𝐠𝐫𝐚̷𝐦𝐦̷𝐞̷𝐫̷

💎 Channel: @DevelopixPython