Python Hints

Guido Van Rossum رو قطعا دیگه می‌شناسید (خالق پایتون) امروز یک بحثی دیدم مخالف ایشون و تصمیماتی که گرفته و تاثیراتی که گذاشته روی Cpython نمیخوام وارد جزئیات بشم ولی بیشتر بحث راجب mojo بود و پستی که گذاشتم راجب تصمیمی که گرفتند و Typing رو تبدیل به ماژول کردند بجای اینکه بیان ی زبان برنامه‌نویسی (اشتباه) یا یک interpreter دیگری برای پایتون ارائه بدند.

mojo

رو نمیدونم خالق‌هاش بهش زبان برنامه‌نویسی گفتند یا طرفدارهاش ولی خب این اولین بار نیست : Jython, IronPython, IntelPython, .... این موارد هم هدف‌هایی مثل mojo دارند ولی فقط جامعه خاص یا پروژه خاص سراغش میره. من این مورد رو توضیح دادم و برگشتیم سر بحث قدیمی پایتون و کوبیدن پایتون ... GIL (global interpreter lock) شاید باورش برای تازه‌کار یا تخریب گر سخت باشه ولی همین هم یکی از بهترین تصمیمات Guido Van Rossum بوده؛ خیلی از افراد این موضوع رو باور نداشتند و تلاش کردند جایگزین ارائه بدند و نشون بدند که خالق پایتون اشتباه کرده که خب نتیجه مشخص هست تماما همگی شکست خوردند اما این وسط یک پروژه‌ای وجود داره که هدفش donate به جامعه پایتون هست و نه تخریب وضعیت این پروژه هم شکست هست فعلا اما درس‌های زیادی داره اگر دوست داشتید بدونید چرا من از GIL حمایت می‌کنم این لینک رو بخونید : Project GILectomy state Larry Hasting وقتی نهایتا موفق شد GIL رو جایگزین کنه؛ تست های مقایسه‌ای انجام داد و نتیجه‌اش شد این : "With his complicated buffered-reference-count approach he was able to get his "gilectomized" interpreter to reach performance parity with CPython, except that his interpreter was running on around seven cores to keep up with CPython on one." به توانایی Cpython رسید ولی روی ۷ هسته پردازشی درحالی که Cpython همون کار رو روی ۱ هسته انجام میداد. در نهایت اینکه پروژه Gilectomy با ایده‌های جدید همچنان درحال توسعه هست؛ اما همونطور که خالق پایتون گفته بود اگر قرار بود از GIL استفاده نشه و منتظر بمونه شاید هنوز پایتون رو نداشتیم. @PyHints

#Quick من این اخطار‌ هارو همیشه زودتر به دوستان نزدیکم میگم گفتم ازین به بعد بعضی‌هاش رو اینجا هم بگم: اولین : asyncio رو هرچه زودتر یاد بگیرید، پترن‌ها و مفاهیم برنامه‌نویسی Async, Parallel, Concurent قبلتر تأکید زیادی روش نداشتم، اما دیر نیست (توی ایران) روزی که حتی Intermediate python هم توی مصاحبه باید این مفاهیم رو کامل بدونه. @PyHints

خارج‌ از بحث ولی لازم : من تو زندگیم آدم‌هایی رو دیدم که از موفقیت می‌ترسند از چشم خوردن یا ... موفقیت یعنی انقدر می‌ترسند که ترجیح میدهند موفقیتی نداشته باشند، یا اینکه همه‌جا مخفی کنند و منکر موفق بودن یا شدن بشوند. که این خودش باعث می‌شه کم کم افول کنند؛ دقیقاً همونطور که مولوی می‌گه : شکر نعمت نعمتت افزون کند کفر نعمت از کفت بیرون کند حالا دلیل منطقی این قضیه چیه ؟ شبکه سازی، من و همه‌ی افرادی که میشناسم خیلی از موفقیت‌هارو مدیون شبکه آدم‌های اطرافمون هستیم، داستان پارتی‌بازی و ... نیستا (دهنمون سرویس شده) ولی همونطوری که شما هیچوقت نمی‌تونی، آدمی که اصلاً نمی‌شناسی رو بعنوان پارتنر انتخاب کنی توی کار هم آدمی که هیچوقت باهاش کار نکردی و کد زدنش رو ندیدی رو نمی‌تونی تایید کنی یا برای کار به شرکت معرفی کنی (اگر بد باشه، برای خودت هم بد می‌شه) و وقتی از موفقیتت چیزی نگی یا پنهونش کنی، این شبکه درست ساخته نمی‌شه و یا به درستی شکل نمیگیره. این بخشش برای تازه‌کارها ☝️☝️☝️ اما ی بخش دیگه هم هست، توی این هفته یکی از دوستانم توی ایران کار پیدا کرد با مبلغی که توی ایران واقعاً قفل هست. ۵ برابر دستمزد شرکت‌های خصوصی و اونایی که پرداخت خوبی دارند. شبکه‌ی آدم‌های اطرافمون، خیلی تلاش داشتند که این موضوع رو تماماً گردن شانس بندازند (میدونم از نظر علمی اثبات شده ۵٪ شانس برای موفقیت ۱۰۰٪ لازم هست و شانس منطقی هست) ولی هیچکس نگفت : اون هفته‌ای که جمع رفته بودند شمال، این دوستمون نرفت چون دوره‌ شرکت کرده بود کسی نگفت، توی تور خارج از ایران، هیچوقت با بچه‌ها نرفت چون داشت تمرین میکرد و .... هیچکس زحماتش رو ندید، وقتی صحبت‌ها تموم شد واقعاً ناراحت بود چون احساسش این بود که کسی تلاش‌هاش رو ندیده و کسی هم چشم دیدن موفقیتش رو نداره خواستم بگم اگر شما هم همچین شرایطی براتون پیش اومد آدمای اطرافتون رو عوض کنید بجای اینکه منکر موفقیت بشید‌، اگر آدمای اطرافتون چشم دیدن موفقیت شمارو ندارند معلوم هست توی این سال‌ها کنار آدمای اشتباهی بودید و حالا که هدف موفق شدن هست باید بدونید قدم اول، شبکه سازی درست هست و برای شبکه‌ سازی درست باید خودتون رو ثابت کنید و موفقیت‌ هاتون رو نشون بدید. و برای اونایی که میگن خوش بحال فلانی که ماهی ۱۰۰-۲۰۰ میلیون یا بیشتر در میاره، کاش منم می‌تونستم و ... باید بگم : فلانی از خیلی چیزا، تفریحات و ... گذشته تا به اینجا رسیده شما که از مهمونی هم نمی‌گذاری بیخود می‌کنی حرف شانس میزنی برای اون افرادی هم که به موفقیت رسیدن (حتی پله‌های اولیه) : no one knows the price you paid, so don't care.

این باگ ۱ ماه تیم رو درگیر کرده بود : توسعه و تست همزمان بصورت پارالل توی تیم‌هایی که هستم پیش میره (اگر تعداد نیرو کافی باشی) یک بخشی از کد رو داریم که همه‌ی تست هارو به درستی پشت سر میذاره، حتی تست‌هایی که توی pipeline و CI/CD داریم همه چیز حتی بصورت هفتگی روی سیستم ها درست کار می‌کنه اما بمحض اینکه میره روی سرور تست‌ خصوصی یا A/B test سرعتش تا ۲۰ برابر کندتر می‌شه شایدم بیشتر ولی این مشکل رو روی سیستم دولوپر‌ها نداریم. پیدا کردن این مدل باگ‌ها خیلی سخت می‌تونه باشه، ولی خب بالاخره پیداش کردیم. مشکل چی بود: if item in mylist: همین خط کد، ۲ تا مسئله داشتیم، ۱- نیروی junior ایی از طرف شرکت به تیم اضافه شده ۲- توی تیم DevOps هم چون کار روتین شده بوده، سپرده‌اند به یک نیروی Mid-level نگهداری رو و همزمان ۲ تا خطا انجام شده : ۱- نیروی تیم توسعه و استفاده از in توی پایتون ۲- نیروی تیم DevOps و تبدیل یکی از pipeline های تست، ازش پرسیدند چرا انقدر تست طول می‌کشه بنده خدا رفته چک کرده دیده یک دیتاست بزرگ داریم برای تست اومده این رو با یک دیتای کوچیکتر جایگزین کرده و چون نیروی junior توسعه دهنده هم سواد کافی نداشته روی mylist توی مثال بالا برای چک کردن اینکه آیا یک نمونه‌ای وجود داره یا نه از in استفاده کرده، که روی حجم بالای دیتا منبع اصلی کند بودن هست : راهکار : ۱- چون روی دیتاهای حجیم کار می‌کنیم، DevOps نباید دیتای تست رو تغییر میداد (اینجوری باگ خیلی زودتر خودش رو نشون میداد) ۲- نیروی تیم توسعه نباید از in و list استفاده میکرد : ۲-۱ : اول به این دلیل که ما اندیس داده رو نمی‌خواهیم فقط وجود یا عدم وجودش توی کدها مهم بوده که نوع داده‌ای set بسیار اینجا کمک کننده بود, همین که بدونیم ۱ مورد وجود داره برامون کفایت می‌کنه این یعنی فضای جستجو کوچکتر ۲-۲ : دستور in بطور کلی کند هست (برای list, set کوچیک خوبه) باید بجاش از الگوریتم‌ها و ساختمان داده درستش استفاده میکرد که Tree گزینه خوبی هست قطعاً. دو تا اشتباه همزمان می‌تونه ۱ ماه همه‌ی تیم رو سردرگم کنه نکته‌ی مهم : حواستون باشه کجا از in استفاده می‌کنید و مهمتر اگر برای داده حجیم کد میزنید حتماً یکبار روی این حجم داده هم تست انجام بدید.

همونطور که قبلاً گفتم از وضعیت آماری پست‌ها برای انتخاب مطالب و ادامه دادن یا ندادن موضوعات استفاده می‌کنم. کمترین میزان Reaction, Share رسید به این مطلب ازین مدل مطالب دیگه توی کانال نخواهیم داشت (هرچند بسیار مهم هست بنظرم) حذف میشه این پست هم 👌

کامنت بذارید از حدس‌ها منم سطح کانال دستم میاد هممون هم اینجا داریم یاد میگیرم 🌹

یک مطلبی توی صحبت‌های دوستان به ذهنم اومد که راجبش صحبت نکردم سطح : Super Senior توی پستی که روش Reply زدم گفتم اگر list رو بخوایم از نظر حافظه بهینه کنیم بهتره از array, numpy استفاده کنیم. حالا اگر بخواهید سرعت list رو بالا ببرید می‌دونید چیکار باید بکنید ؟! (درحد سوال مصاحبه هم شاید ازتون پرسیده نشه هیچوقت بخاطر سطح بالای مطلب) حدس بزنید، پاسخ رو بعداً همینجا می‌نویسم، سر فرصت هم مثال خواهم زد.

مشکل اینه که خیلی از دوستان این حجم رو که می‌بینند سریع به load کردنش توی RAM فکر می‌کنند 10MB حجمی نیست، بعد کدهاشون رو تا جایی که توانش رو دارند Optimize می‌کنند و در نهایت هم وقتی نمی‌تونند بهبودش بدهند می‌گن پایتون سرعت کمی داره این موضوع قبول ولی بخشی ازین داستان برمیگرده به این موضوع که شما معماری سیستم‌ رو نمی‌شناسید و کاری رو قبول کردید که نیاز به این دانش داره اهمیت جدول بالا هم دقیقاً همینجا هست، ی موضوعی که همیشه توی کنفرانس‌ها و مراسم معرفی CPU ها اعلام می‌شه سرعت Compression, DeCompression هست، که ۹۹٪ بهش دقت نمی‌کنند. اما این نشون میده اگر من دیتای این مثال ینی ۱۰ مگابایت رو فشرده کنم و از cpu های نسل جدید هم استفاده کنم، می‌تونم دیتای فشرده شده رو وارد L3 Cache توی مثال بالا، کنم و بجای سرعت خوندن دیتای 100 ns از سرعت خوندن داده 30 ns بهره ببرم که خودش به تنهایی یعنی 1/3 شدن زمان، باقیشم بیخیال ... قطعاً جدول بالارو توی همه‌ی کتاب‌های درسی و ... دیدید اما از کاربردش هم اطلاع داشتید ؟ یا دلیل اینکه همیشه سرعت compression, decompression اعلام می‌شه رو چطور ؟ @PyHints

اهمیت این جدول خیلی مهمه، بعضی وقت‌ها توی مباحث Optimization شرکت که وارد می‌شیم، (البته برای pipeline های پردازشی که سالی ۱ بار آپدیت می‌شوند و ۳۶۵ روز ۲۴ ساعت و ۷ روز هفته در حال پردازش دیتا هستند بدون تغییر حتی ۱ خط کد) یک همچین جدولی رو از تیم سخت‌افزار تحویل میگیرم؛ توی بحث ما Access Time رو کاری نداریم (چون فقط نسبت سرعت مهم هست و همین که ترتیب رو میدونیم کفایت می‌کنه) اما چیزی که اهمیت پیدا می‌کنه Size هست. اگر بخوام اهمیتش رو ساده توضیح بدم، فرض کنید روی کدهاتون Scalene رو اجرا کردید و دیدید که Cpu idle time یا همون زمان بیکاری cpu زیاد هست، و فرض کنید شما دارید دیتارو توی ram استفاده می‌کنید. فرض کنید سناریو realtime هست و این بخش حدوداً ۱۰ مگ دیتا در هر لحظه بهتون میده 10 MB خیلی حجم زیادی هست وقتی روی دیتای متنی کار می‌کنید. مشکل کجاست ؟ پست بعدی

راجب پروفایلر که قطعاً ی روزی سر فرصت مطلب می‌نویسم و آموزش میذارم مثل مطلبی که در مورد dis نوشتم و نحوه تحلیل خروجی‌ پروفایلر‌ها رو خواهم گفت چون صرف اینکه فقط زمان اجرا رو بخونید، بهش Profiling نمیگیم؛ نکته‌ای که متأسفانه ۹۰٪ آموزش‌ها در همین حد بهش می‌پردازند. اما تا اون زمان : ابزاری که خودم استفاده می‌کنم توی این سال‌ها Scalane Github هست (تلفظ درستش: اِسکِیلین) چراکه نه تنها برای Cpu بلکه Memory, Gpu هم اطلاعات profiling رو میده و الگوریتم‌هاش انقدر هوشمندانه نوشته شده که سرعت اجرا خوبی داره. Profiling شاید بنظر مطلب خیلی سطح بالایی باشه و نیروی سطح پایین‌تر فکر کنه که نمی‌تونه ازش بهره بگیره ولی اینطور نیست اتفاقا بیشترین کمک رو به نیرو‌های در مسیر یادگیری می‌‌تونه بکنه.

اینم سوال جالبی بود که از من شد (چند هفته گذشته ولی خب ...) اگر قرار بود از اول شروع کنی، چه مطالبی رو دنبالش میرفتی ؟ قطعاً برای برنا‌مه‌ نویسی : بجای اون همه جابجایی فقط ۳ تا زبان رو نگه می داشتم Assembly, Rust, Python3 نکته اینه که من خیلی آدم سمت ترمینال و سروری هستم و بیشتر جذب این موارد میشم تا محیط گرافیکی و ... قطعاً توی این مسیرم باز هم Cisco CCNA, CCNP رو میخوندم. قطعاً بازهم Linux RedHat رو آزمون‌هاش رو میدادم (مدرک lpic رو دوس ندارم چون خیلی کاغذی هست) این موارد واجباتی هستند که فکر می‌کنم خیلی از سواد امروزم رو مدیون یادگیریشون هستم.

برای راه حل راهکار زیاد هست : ۱- کش رو برای هر instance جدا کنیم؛ توی نمونه‌ کدهایی که ما داشتیم این راهکار برامون مناسب بود. ۲- پردازش مربوط به این بخش که نیاز به cache داره رو کلا ببریم توی یک ماژول جدا و functional بنویسیم کدش رو ۳- بیایم از __new__ و meta class programming استفاده کنیم به همراه روش اول و اینطوری بین instance های مختلف هم می‌تونیم cache رو نگه داریم.

توی پستی که رفرنس دادم اگر نحوه صدا زدن تابع توسط decorator رو ندونید شاید یک مقدار سخت باشه اتصال این دوتا مطلب به هم دیگه داخل کادر سبز کاری هست که واقعا lru_cache می‌کنه مشکل اینه که حالا که میره توی global دیگه garbage collector روش اعمال نمی‌شه چون همواره رفرنس خواهد داشت شاید بهتره توی این مثال

def __del__

رو هم بذارید و پرینت بزنید تا ببینید که اجرا نمی‌شه و این ینی garbage collector دست بهش نمیزنه حالا راه حل چیه : (پست بعدی)

ازونجایی که به جواب رسیدید مشکل اینه که

lru_cache

و cache (پایتون ۳.۹ به بعد) رو نباید روی method ها بزنیددایکومنت‌های مختلف هم بهش اشاره کردند. دلیلش هم که قبلا توی این پست گفتم : بزودی در این مکان لینک قرار می‌گیرد توی پست بعدی بیشتر توضیح میدم.

جواب سوال اینجاس ☝️ اینم ی راهنمایی (گفته بودم انقدر ساده تو مصاحبه نمیاد) الان دقیقاً شده سوال مصاحبه‌ای 😬 سطح Mid-level, Senior

وقتی از chatGpt یا ابزارهای مشابه استفاده می‌کنید باید چندین برابر مراقب باشید. متاسفانه این ابزارها شعور درستی ندارند؛ شاید مثل یک senior توضیح بدهند یا کد تمیز بزنند ولی درک درستی ندارند (برای همین من اصلا به نیروی

Junior, Mid-level 

حتی پیشنهاد نمی‌کنم) یک کد مشابه کد بالا باگی بود که توی کدهای پروژه پیدا کردم و چندروزی تیم رو هم درگیر کرده بود. بنظرتون علاوه بر موردی که با print مشخص کردم چه باگ فاجعه‌بار تری توی کدهای بالا وجود داره ؟

توی هفته گذشته به یک جمع‌بندی دیگه هم رسیدم درصد جوگیری توی ایران خیلی بالاس، Mojo رو قطعاً دیدید دیگه ؟ اگر ندیدید خوش بحالتون قبل ازین که جوگیر بشید، مثل ۱-۲ از همکارای مثلاً senior من توی جلسه بجای راهکار‌های Optimization راهکار بدید از mojo استفاده کنیم در نظر بگیرید: ۱- پروژه Typing توی پایتون که این روزا بسیار طرفدار داره توی دنیای پایتون : وقتی اولین بار توسعه داده شد، ایده اصلی این بود که Python static type بشه، که خود شخص Guido van Rossum متقاعدشون می‌کنه بجای اینکار Typing رو‌ اضافه کنند. ۲- این اولین بار نیست که اینکار داره انجام می‌شه یا تلاش می‌شه انجام بشه ولی خب شاید بهترین هست ۳- کسانی که پشت این پروژه هستند یک پروژه خوب دیگه هم دارند که چون استاندارد‌های صنعت رو رعایت نکرده بود هیچوقت صنعتی نشد FastAi منم بیشتر فکر می‌کنم Mojo بدرد Data science, ... میخوره نه پروژه صنعتی و نه software engineering ولی اگر دنبال ی چیز باحال میگردید که هم آینده داشته باشه هم وقت خالی شمارو پر کنه هم سرعت خوب بهتون تحویل بده Rust رو یاد بگیرید. درنهایت : لطفاً جوگیر نشید 🌹❤️

مورد ۱، ۶، ۷ ۸۰-۹۰٪ سوالاتی که دوستان بصورت پیام خصوصی برای من می‌فرستند ازین به بعد جواب نخواهم داد چون باعث میشه سوالات مهم رو نتونم پاسخ بدم 🌹

چندتا نکته راجب پست‌های بالا : اگر این موارد رو بلد نبودید؛ بلد نیستید و یا حتی توضیحات بالا براتون سنگین هست : ۱- ممکنه من بد توضیح داده باشم (تایپش واقعا ۱۰ برابر توضیح رو سخت‌تر می‌کنه) ۲- یادتون نره سطح مباحث mid-level به بالا هست اونم mid-level واقعی نه ازینا که بعد از ۲ سال کار کردن سطح خودشون رو بالا میبرند. این پست استثنایی هست و سطح

Upper Senior 

هست پس اصلا نگران نشید. احتمالا بسیاری نیروی senior می‌بینید که حتی اگر اسم dis module رو شنیده باشند تفسیر کردنش رو بلد نیستند؛ بازم میگم چون نیازی نداشتند اما الان با جزئیات خوبی می‌دونید که دفعه بعدی که برای کدهای پایتونی و توی محیط توسعه مورد علاقتون debugger رو اجرا می‌کنید چطور عمل می‌کنه و مقادیر متغییرها؛ byte code؛ خونه حافظه و ... همرو بهتون نشون میده بخش عمده‌ای از اطلاعاتش رو ازینجا بدست میاره حالا علاوه بر اینها شاید درک کنید که چرا نوشتن از Profiler برام سخت هست (بیشترم بخاطر توضیح نحوه تفسیرش هست) در نهایت اگر سوالی بود تو گروه بپرسید؛ اگر نه که امیدوارم مفید باشه براتون لطفاْ reaction رو فراموش نکنید؛ وقتی کم می‌شه من فقط سیگنال میگیرم که اون پست یا موضوع رو دوست نداشتید و نمی‌خواید راجب اون یا موضوعات مشابه بشنوید (جدی میگم) دلیل ادامه ندادن بعضی مباحث هم همین هست واقعا روی تمامی پست ها reaction رو داشته باشیم لطفا ارادتمند عباسی @PyHints