Python Hints
СтатистикаPython tips and tricks The Good, Bad and the Ugly توی این کانال فقط قرار هست در مورد core python صحبت کنیم. این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از ۱۰ سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازهکار) Admin: @Abbasi_ai
- Последний пост
- 9 авг.
- Последнее чтение
- 15 авг.
- Постов за неделю
- 0
- Всего постов
- 27
- Тип
- открытый
- Язык
- персидский
- Категория
- Технологии
- В каталоге с
- 12 авг.
- 1/24сутки в ленте
- 2 611
- 1/48двое суток
- 2 992
- 1/72трое суток
- 3 227
Оценка по просмотрам недавних постов: пост набирает почти всё за первые сутки.
Посты
داشتم داستان ۲ هفته troubleshoot کردنم برای یک شرکت رو مینوشتم و اینکه ۷ نفر قبل من رفته بودند و راهکاری پیدا نشده بود. حتی بهشون جابجایی استک پایتون رو هم پیشنهاد داده بودند. و حتی اینکه خرید سرور تا ۳ برابر قویتر هم کمکی نکرده بود. که سیستمم خاموش شد (نوسان برق) خلاصهاش رو بگم، تیبل refresh token رو براش بکگراند جاب بنویسید تمیز کنه. که اگر یکی refresh token رو اشتباهی گذاشت روی 1 ساعت و ۵ میلیون یوزر داشتید توی چندین ساعت تیبل بزرگ نشه، شما اون باگ رو توی ۳ ساعت بعدش حل میکنید ولی ماها بعد حجم اون تیبل چندین برابر میشه و سرچ کردن توش تمام کوئریها رو کند میکنه و میشه چیزی که نباید بشه و خفت میشید. تقریباً داشتم از پیدا کردن راهکار ناامید میشدم که مشکل رو پیدا کردم. پینوشت: ۱- دسترسی گرفتن به سرور پروداکشن سخت بود، شاید تنبلی شایدم هرچیز دیگری نفرات قبلی اینکار رو نکرده بودند. ۲- من بعد از اطمینان از کد و البته تست لود و پروفایل روی سرور dev مطمئن شدم باید روی پروداکشن دنبالش بگردم ۳- حتی فکرشم نمیکردم مشکل از refresh باشه چون کد تغییری نکرده بود (۱ سال این بخش کدها دست نخورده بود، گیتلاگ) و البته آخرین تغییر فایل .env روی سرور هم برای ۷ ماه قبل بود ولی مشکل ۲ ماه پیش شروع شده بود. ۴- اگر سوال پیش اومد چرا refresh رو توی دیتابیس داریم در مورد jti, family id توی jwt بخونید.
بنظرم ویدئوهای کنفرانس امسال خیلی کم داره دیده میشه PyData Youtube
یک آپشن روی sqlalchemy برای relationship هست که شخصا خیلی دوسش دارم؛ باعث میشه به کوئری که سمت دیتابیس میفرستم فکر کنم بجای اینکه سادهترین راه رو انتخاب کنم. هرجا هم که نیاز دارم دولوپرها به کوئریهاشون دقت کنند حتما ازش استفاده میکنم. lazy = "raise" الان داشتم خروجی پروفایلینگ یک پروژه رو نگاه میکردم؛ توی RandRng گفتم راجبش. دیدم خیلی کوئریهای دیتابیس زمان بر هست؛ ی سرچ توی مدلهای دیتابیس زدم و همهی relationship هارو بهش؛ lazy = "raise" اضافه کردم؛ تا دلتون بخواد ارور میگیریم حالا ولی باعث میشه همه به کوئریهاشون فکر کنند. گفتم اینجا هم بذارم شاید بدرد کسی خورد.
این ترکیب به راحتی میتونه خیلی از پروژهها رو از Postgres به Sqlite منتقل کنه؛ Sqlite + Litestream توی خیلی پروژهها برای خودم پیش اومده که یک دیتابیس نیاز داشتم؛ شاید ۵-۱۰ تا جدول ولی اینکه فقط روی یک سرور نباشه هم برام مهم بوده که خب سرویسهای کلاد رو استفاده میکردم. همزمان هم Latency میرفت بالا هم کلی هزینه پرفورمنس واسه سربارهایی کار کردن با Postgres میدادم درحالی که به ۹۰٪ اون ویژگیها نیازی نداشتم. الان داشتم دنبال یک راهکار برای یک پروژه دیگه میگشتم و واقعا دلم نمیخواد Latency و Throughput ام بخاطر استفاده از Postgres کم بشه و بعد بشینم اپتیمایز کنم. بخصوص اینکه این دیتابیس هیچ دیتای حساسی نداره و فقط همین که دیتاها از بین نره برام مهم هست. به چندتا راهکار رسیدم که بنظرم این ترکیب برای کار من برنده هست بخصوص اینکه RustFS رو همین الان داریم : Turso + Litestream + Rustfs بعد از پروژه یادم باشه نتایجش رو هم میذارم. پینوشت: اگر خواستید بیشتر بررسی کنید Turso Litestream Rustfs
اینو یادداشت کرده بودم که بذارم: تقریبا ۱.۵ سال پیش روی یک پروژهای کار میکردم (فکر کنم گفتم جزو معدود پروژههایی بود که از اول توی پروژه بودم) امشب با مدیرعامل شرکت و صاحب پروژه صحبت میکردم (شاید پروژه دوم) میگفت علاوه بر دولوپرهای بعدی ادمین دیتابیس هر چندوقت یکبار که روی دیتابیس کار میکنه ی دمش گرم هم به ما میگه. من استانداردهای زیادی رو رعایت کردم روی اون پروژه ولی این ۵ خط بنظر میاد خیلی بچههایی که روی دیتابیس کار میکنند رو راضی نگهداشته class Base(AsyncAttrs, DeclarativeBase): metadata = sa.MetaData( naming_convention={ "ix": "ix_%(column_0_label)s", "uq": "uq_%(table_name)s_%(column_0_name)s", "ck": "ck_%(table_name)s_%(column_0_name)s", "fk": "fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s", "pk": "pk_%(table_name)s", } ) من همیشه اینکار رو برای خودم میکنم که توی همه پروژههام یک استاندارد رعایت شده باشه و راحت بتونم دیباگ کنم و بخونم؛ خلاصه برای راحتی خودم هست. این حرفا رو که امشب شنیدم گفتم بذارم شما هم توی پروژههاتون رعایت کنید. امیدوارم مفید باشه
16-week-fastapi.md
#Backend_RoadMap_2025 قبل از اینکه بخواید این roadmap رو دنبال کنید باید پست قبلی رو بخونید. یک نکتهای که اضافه کنم؛ توی جلسات و ... که بحث شد من اصلا قرار نیست هیچ چیزی رو آموزش بدم (اشتباهات رو کمک میکنم حل بشه و ...) اما اینکه آموزش بدم FastAPI چیست و…
#Quick from pydantic import SecretStr لطفا ازین مورد استفاده کنید؛ نشستم لاگ سرور یک پروژه رو میخونم تمام اطلاعات سرور و اطلاعات کاربراش خیلی زیبا و خوانا توی لاگ هست. قبلا هم یک موردی رو توی @pyhints یاد دادم برای لاگ نویسی موارد مهم. لطفا از هر دو استفاده…
#Quick from pydantic import SecretStr لطفا ازین مورد استفاده کنید؛ نشستم لاگ سرور یک پروژه رو میخونم تمام اطلاعات سرور و اطلاعات کاربراش خیلی زیبا و خوانا توی لاگ هست. قبلا هم یک موردی رو توی @pyhints یاد دادم برای لاگ نویسی موارد مهم. لطفا از هر دو استفاده کنید؛ هیچ چیز مهمی نباید توی لاگ نوشته بشه. بخصوص ایمیل و شمارهتماس کاربر.
Python Hints pinned a photo
LLM قراره جای برنامه نویسهارو بگیره ؟ من که کدم رو + دستورالعمل ریفکتور دادم تا برام تمیز کنه و خروجی که توی تصویر هست نصف باگهای مدلهای LLM رو من درآوردم باید بهم هزینه پرداخت کنند واقعا پینوشت: تازه ۳۵ دقیقه هم طول کشید. خودم میزدم ۲۰ دقیقهای تموم میشد.
تا ۱۰۹ هزار درخواست در ثانیه رو میتونه جواب بده روی این بنچمارک؛ من اگر سرویسم به ۶۰۰۰ درخواست در ثانیه هم برسه یک چیزی در حد Stackoverflow هستم (بر اساس مصاحبه Roberta Arcoverde میگم) برای تعجب بیشتر شما؛ توی مصاحبه به monolithic بودن معماری سیستم اشاره…
یکبار برای همیشه؛ زرتی نرید استک بکند رو عوض کنید تا تعداد درخواستهاتون به ۵۰ تا در ثانیه رسید. اگر سرویس بکند شما نمیتونه این تعداد درخواست رو جواب بده مشکل شما پایتون نیست؛ مشکل شما سواد هست. واقعا خسته شدم طرف تعداد درخواست در ثانیهاش به ۳۰ تا هم نمیرسه…
یکبار برای همیشه؛ زرتی نرید استک بکند رو عوض کنید تا تعداد درخواستهاتون به ۵۰ تا در ثانیه رسید. اگر سرویس بکند شما نمیتونه این تعداد درخواست رو جواب بده مشکل شما پایتون نیست؛ مشکل شما سواد هست. واقعا خسته شدم طرف تعداد درخواست در ثانیهاش به ۳۰ تا هم نمیرسه میگه ما باید به Go مهاجرت کنیم. حتما روی ۱۰۰ تا هم باید به Rust مهاجرت کنی ؟ من دوتا تصویر میذارم؛ تصویر اول بر اساس این بنچمارک مستقل با chatgpt جدول شده برای هر کدوم تعداد درخواست بر ثانیه رو مینویسم: 1) Django + Postgresql: 31,000 - 33,000 2) Fastapi: 11,000 - 109,000 مثلا توی همون بنچمارک کانفیگهای مختلف Fastapi رو ببینید چقدر تفاوت داره از ۱۱ هزار درخواست برای یک مورد تا ۱۰۹۰۰۰ درخواست. بدون تغییر فریمورک اصلی و کد 3) Gin: 110,000 و در نهایت فریمورک مورد علاقه خودم : 4) Axum + Postgres: 1,115,000 بله میلیون با اینکه من خیلی به Axum علاقه دارم و بسیار هم توی کد زدن روش راحت هستم ولی تا الان نشده مشاور یا مدیر فنی تیمی باشم و Axum رو پیشنهاد بدم حتی روی بکندهای با تعداد درخواست بسیار بالا گزینه اول همیشه FastAPI هست. ادامه پست بعدی
class Engine(): _instance = None _lock = threading.Lock() def __new__(cls): if cls._instance is None: with cls._lock: if cls._instance is None: .... توی کد بالا بنظر شما چرا if cls._instance دوبار استفاده شده ؟ اگر بلد نیستید اشکالی نداره (قراره یاد بگیرید) قبل از دیدن راهنماییها با دقت بهش فکر کنید ببینید متوجه دلیلش میشید ؟ راهنمایی: به حالت async اجرای این Singleton فکر کنید اسم این پترن : double check locking هست یک سری موارد رو چندوقت پیش توی مصاحبههام با شرکتهای بزرگ دیدم؛ الان دارم روی یک پروژه کار میکنم این مورد رو نیاز داشتم پیادهسازی کنم گفتم همینارو سوال جواب کنم برای یادگیری دوستان.
95% of enterprise AI deployments fail to deliver value در یک حرکتی چندتا از این شرکتهای AI فروش داخلی (کاسبان تحریم) روی موجهای اخیر درحال تلاش برای خوروندن LLM به شرکتهای دیگر هستند. شرکتهایی که همینطوری بخاطر تحریم؛ جنگ؛ قطعی اینترنت و تعطیلی به زور سرپا موندند. برای همین خواستم دوتا مورد رو یادآوری کنم: اولین مورد گزارش MIT روی میزان سودآوری AI (که ۹۵٪ میزان بازگشت 0 داشتند) legal.io مورد دوم؛ تجربه شخصی بنده توی کار با تیمی از مهندسها که مدتی قبل منتور اونها بودم. ( استفاده درست از LLM ها برای مهندسی کامپیوتر ) با نهایت احترام به شرکتهای AI داخلی که واقعا innovation دارند و در تلاش برای پیشرفت جامعهی ایرانی هم هستند.
من یک توضیحی روی این پست قبلی درباره کانفیگ neovim خودم بدم. دوستان فلسفه کانفیگهای neovim این نیست که دانلود کنید و تمام اونوقت همه چیز روی سیستم شما هم عالی کار کنه و همه چیزش رو شما هم دوست داشته باشید. من به درخواست یکسری دوستان مجددا پروژه رو برای آخرین نسخه neovim و کانفیگها آپدیت کردم البته الان. پس چرا به اشتراک میذاریم ؟ معرفی و یک چیزی برای شروع؛ اگر تلاش کرده باشید یک مورد رو از اول برای خودتون کانفیگ کنید (بخصوص دفعات اول) خوندن و کانفیگ درست انجام دادن میتونه از ۱-۲ روز تا ۱-۲ هفته زمان ببره ولی اگر یکی قبلا یک بیس براتون توسعه داده باشه این زمان بخصوص با وجود LLM ها میتونه به ۱-۲ ساعت برسه. هیچکس هم علاقه نداره Lua یادبگیره که فقط Neovim کانفیگ کنه. اما چندتا نکته : ۱- اگر یک چیزی میخواید که دانلود کنید و کار کنه؛ بهترین گزینه برای شما vscode هست ۲- اگر سنگینی vscode اذیتتون میکنه چون روی چند زبان کار میکنید یا پروژه شما خیلی بزرگ هست گزینه بهتر Zed هست. ۳- اگر تایپ ۱۰ انگشتی بلد نیسیتید؛ vim, neovim برای شما مناسب نیست ۴- اگر فقط روی یک زبان برنامهنویسی کار میکنید و vscode, zed کند نمیشه براتون یا اگر علاقهای به کانفیگ کردن جزئیات ندارید بازم neovim بدرد شما نمیخوره ۵- اگر فکر میکنید neovim کمک میکنه تندتر کد بزنید چون شرتکاتهای خوبی داره؛ بهتره برای ادیتوری که روش هستید وقت بذارید و شرتکاتهای همون رو یاد بگیرید. قبل از توضیح بیشتر : یادتون باشه neovim دائما درحال آپدیت شدن هست؛ کانفیگها هم همینطور و بسیاری از اونها بین ورژن و گیتکامیت تغییرات breaking هم داره شخصا ۶ ماه یا ۱ سال یکبار آپدیتش میکنم یا وقتی یک سیستم جدید رو کانفیگ میکنم و میبینم دیگه ورژنها نمیخونه. ۶- قبل از اینکه با کانفیگ neovim دیگران کار کنید سعی کنید کلیدهای اصلی vim یا neovim رو یاد بگیرید. ۷- فلسفه کلیدها این هست که همه چیز روی home row باشه با استفاده زیاد از Ctrl, Alt فقط مزایای شرتکاتها رو از دست میدید و نشون میده این ادیتور برای شما نیست. ۸- هیچ چیز خفنی هم روی استفاده از neovim, vim نیست آدما شمارو با کدی که زدید قضاوت میکنند نه با ادیتوری که استفاده کردید. ۹- در نهایت از کاستومایز کردن لذت ببرید؛ این ادیتور مال شماست.
اگر به تنظیمات neovim من روی گیتهاب سر زده باشید و کمی هم بهش نگاه کرده باشید میدونید که تنظیمات مربوط به typecheck من یک مقدار هکی هست؛ ترکیبی از ruff, pyright, mypy و یک سری توابع کاستوم برای پیدا کردن .venv داخل پروژه و ... کار میکرد ؟ بله خیلی از دوستان حتی از عملکردش رضایت هم داشتند ولی روی پروژههای بزرگ بعضی وقتا واقعا اذیتم میکردم بخصوص اینکه شدیدا کند بود. یک پیام توی گروهی دیدم (خیلی قدیمی بود و گروه رو من خیلی وقت بود باز نکرده بودم) درمورد بازنویسی pyrefly با Rust و بحثهای پیرامون اون یک سری به سایتش زدم و دیدم چقدر عالی حالا دیگه extension هارو هم داره و با Mason هم کار میکنه. اگر خواستید بدونید تفاوت سرعتش نسبت به جایگزینها چقدر هست؛ صفحهی اصلی رو میتونید چک کنید: مثلا برای پروژه instagram (بله این پروژه روی پایتون هست) Pyrefly: 13.4s Pyre: more than 300s من حوصلم نشد تا آخر Pyre صبر کنم ولی از چیزی که نوشتم هم گذشت یا برای پروژه pytorch : Pyrefly: 2.4s Pyright: 35.2s MyPy: 48.1s دوستانی که روی پروژه بزرگ کار کردند یا CI/CD نوشتند برای پروژه یا حتی pre-commit رو فعال کردند کاملا میدونند من چی میگم. پیشنهاد میکنم حتما تستش کنید؛ برای من بسیار بسیار مفید بود واقعا اگر هم خواستید میتونید از کانفیگ neovim بنده استفاده کنید My Neovim Config البته فعلا روی برنچ feat/pyrefly هست تا چندروز بیشتر و روی پروژههای دیگر هم تستش کنم و مطمئن بشم همه چیز درست کانفیگ شده.
نکته دوم و چیزی که در ادامه بحث اول باید بگم؛ تعداد به اشتراک گذاری و ذخیره پستهاست.
توی پست مربوط به رودمپ بکند : Backend Roadmap برای آخرین مورد گفتم که حتما همهی بچهها باید از روز اول ADR بنویسند؛ سر این موضوع با هیچ کدوم از بچهها شوخی ندارم. اما خیلیها (مثل بچههایی که باهاشون کار میکنم) پرسیدید چرا باید ADR بنویسیم بهتر نیست وقتمون رو روی کد زدن و تمرین و یادگیری بذاریم. جواب کوتاه: هیچ ابزار - هیچ کتاب و ... دیگری به اندازه نوشتن ADR شمارو تست نمیکنه و به شما یاد نمیده حتی. اما اگر توضیحات برای قانع شدن میخواید ادامه مطلب رو بخونید: بخش بزرگی از کار یک مهندس نرمافزار (بخصوص توی سطوح بالاتر) یادگیری بحث و مناظره کردن هست؛ چیزی که توی سالهای اخیر همکاریم با بچهها توی ایران خیلی خیلی کم دیدم. این بحثها اکثرا سر چه چیزهایی هست ؟ ۱- از کدوم فریمورک استفاده کنیم ۲- با کدوم استاندارد پیش بریم ۳- دیتابیس چی بذاریم ۴- تست نویسی چطوری باشه ۵- چرا از این ابزار استفاده کنیم یا نکنیم و ... شما هرروز درگیر این بحثها خواهید بود و اینکه بتونید از پیشنهادات خودتون بطور منطقی دفاع کنید موضوع بسیار بسیار مهمی هست. وقتی شروع به نوشتن ADR = Architecture Decision Records میکنید یاد میگیرید ابزاری که دارید انتخاب میکنید رو همه جنبههاش رو ببینید؛ خیلی وقتا ابزارهایی که افراد انتخاب میکنند فقط بخاطر hype هست و جو زده هست اون انتخاب بدون اینکه بدونند آیا واقعا بدردشون میخوره یا مناسب کارشون هست. خیلی وقتا این مکالمه رو شنیدیم: - چرا فلان ابزار رو انتخاب کردید ؟ + گوگل داره ازین استفاده میکنه؛ چی ازین بهتر آره دوست من ولی گوگل چندین میلیارد کاربر داره و تو به زور به ۵ هزارتا میرسی. گوگل هزاران نفر توسعه دهنده داره ولی تیم تو به زور به ۱۰ نفر میرسه. گوگل میلیاردها دلار خرج زیرساخت و دستمزد و ... میده. تو زیرساختت به زور ۱۰۰ هزار دلار میشه. برای خود من موقع بحث سر موضوعاتی که بچهها باید یاد بگیرند برای توسعه بکند همین موضوع پیش اومد یکی از بچهها گفت برای سرویس ارسال ایمیل از celery استفاده کنیم پس اینم بنویسید؛ که اگر نگاه کنید من ممنوع کردم استفادهاش رو celery سرویس بسیار بزرگ و سنگینی هست. برای پروژههای کوچیک اشتباه هست که توی قدم اول برید سراغش؛ اما اگر کسی بتونه ADR خوب بهم بده قطعا قبول میکنم. درسته وقتی تنهایی کد میزنید به ADR نیازی نیست اما نوشتنش باعث میشه یاد بگیرید بحث کنید؛ توی نوشتن ADR معمولا شما به چندتا ابزار میرسیدو باید این چیزها رو توضیح بدید : ۱- این ابزارها برای چه کاری هستند و چرا فکر میکنید توی پروژه لازمشون داریم ؟ ۲- چرا هرکدوم از ابزارها رو در نظر گرفتید؟ (چرایی مهم هست) ۳- انتخاب شما کدوم بوده ؟ و البته چرا ؟ ۴- نقاط قوت و ضعف ابزاری که انتخاب کردید چی هست ؟ ۵- نقاط قوت و ضعف ابزارهایی که انتخاب نشدند چی هست؟ ۶- تحت چه شرایطی ابزارهای دیگر رو انتخاب میکردید یا اینکه شرایط پروژه چی بود که نقاط قوت ابزار انتخابی شما به باقی موارد و البته نقاط ضعف اون چربید و انتخاب شد. فکر میکنم از سوالها مشخص باشه که چقدر چیز مفید و مهم رو درک میکنید و یاد میگرید. آیا همه پروژهها این رو دارند ؟ به جرات میگم که بیش از ۹۲-۹۳٪ پروژهها و حتی شاید توسعه دهندهها حتی نمیدونند چی هست؛ ولی تمام پروژهها و تمام مدیران فنی و اعضای تیمهاشون هرروز درگیر یکی از این تصمیم گیریها هستند. به مدیرای فنی هم پیشنهاد میکنم توی تیم این موضوع رو داشته باشید؛ خیلی وقتا نیرو احساس میکنه حرفهاش شنیده نمیشه درصورتی که شما میدونید چیزی که پیشنهاد میکنه خوب نیست برای پروژه فقط وقت برای توضیح دادن بهش رو ندارید. معمولا با نوشتن ADR خیلی از بچهها خودشون متوجه میشوند که چرا جواب نه بهشون داده شده.