ابزار جدیدی از astral اومده به اسم uv جاگزینی خواهد بود برای pip, poetry, ...
البته درحال حاضر خیلی خام هست ولی بطور خیره کننده‌ای سرعت بالایی داره حتما یک سری بهش بزنید.

uv: Python packaging in Rust

پ.ن: از cache یک سری پکیج هوش مصنوعی نصب کردم 0.35sec طول کشید همین مورد با pip بیشتر از 30sec زمان می‌بره.
البته بازم میگم؛ هنوز پیشنهاد نمیکنم روی پروژه استفاده بشه.

#Quick

پست قبلی که گذاشتم راجب uv حقیقتا از اینجا متوجه پروژه شدم که تیم‌های
Data Engineering, Backend, Test
توافق کردند از
ruff
استفاده کنند، بخصوص که حالا دیگه vs-code extension هم براش وجود داره و خیلی راحت شده کار بچه‌ها گفتند ما هم بریم سراغش و منم دارم بررسی می‌کنم که نظراتم رو راجبش بدم، نسبت به تمام کانفیگ‌هایی که داریم.


تا اینجا که خیلی خوب پیش رفته (از صبح).

#تجربه

دوره کتابخوانی خودمون
کتاب خوانی با چندتا از همکارای شرکت
مقاله خوانی و ...

باعث شد یک چیزی رو مطمئن بشم؛ ۹۸٪ کتاب خواندن رو بلد نیستیم
البته حق هم داریم، دانشگاه و مدرسه و ... باعث و بانی این موضوع بوده و البته اینکه هیچ کس بهمون یاد نداد یا بهمون نگفت که داریم اشتباه می‌خونیم.

شخصاً این مشکل رو داشتم.

برای مثال: اول هفته با یکی از همکاران شرکت شروع به خواندن یک کتاب کردیم (بخش تحقیقات)
من دیروز کتاب رو تموم کردم و شروع کردم به کد زدن (با اینکه من جاهای دیگه هم کار می‌کنم) وقتی pull request زدم و درخواست peer review دادم، بهم گفت که تازه ۱٫۳ کتاب رو خوانده.

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

۱- خواندن برای آزمون تئوری (مثلاً LPIC)
۲- خواندن برای آزمون عملی (مثلاً RHCSA)
۳- خواندن برای یادگیری نکته‌ای (fluent python)
۴- خواندن برای یادگیری دقیق ( fastapi documentation )

اگر توی همه این موارد فرمول خواندن شما یکسان هست، اگر موقع خواندن (حتی دیجیتال) ورق و قلم بغل دستت نداری

متأسفانه باید بگم که شما کتاب خواندن درست رو بلد نیستید، و همین داره وقتتون رو می‌گیره یا شمارو خسته می‌کنه.

#تعیین_سطح

بعد از سری پست‌هایی که راجب دستمزد بود :
Link

مهمترین سوال اکثر دوستان نحوه تعیین سطح بود،

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

اما جزئی‌تر بخواب بگم :
۱- میزان دانش
مثلاً برای پایتون، آیا می‌دونید
mro, hash
چی هستند و کجا استفاده میشه یا مثلاً
sequence, iterator, iterable
چی هست،
yield, yield from
یا
multi process, multi thread
چه تفاوتی دارند ؟

یا سوالات meta programmig، design principles

۲- غیر از زبان برنامه‌نویسی آیا اطلاعات پایه‌ای مهندسی کامپیوتر رو بلدید ؟
Data Structure, Algorithm, System design

۳- توانایی آنالیز و حل مسئله چطور هست ؟
این بخش همون مباحث
leet code
هست، اما به شرطی که بتونید نحوه حل مسئله رو بلند بلند توضیح بدید.
تعیین سطح یک جا بدرد می‌خوره اونم مصاحبه هست، و چیزی که توی مغز شما می‌گذره‌ رو مصاحبه کننده نمی‌دونه پس باید بتونید همزمان با فکر کردن توضیح هم بدید.

۴- نحوه برخورد با مشکلات، بهت بگن سنیور یا هرچیزی اینجا جایگاهی هست که خودت رو نشون میدی
قبلاً هم گفتم، وقتی درخواست یک فیچر جدید به کاری که برای خودت پلن کرده بودی اضافه میشه و غیر منطقی در برابر پیاده‌سازی مقاومت می‌کنی.
تو سنیور نیستی، سنیور برای هر حرفی که میزنه دلیل منطقی داره (قرار نیست برای جونیور توضیح بده و وظیفه‌ام نداره) اما سوادش اونقدری هست که توی جلسه فیچر جلوی فیچر بدردنخور ایستادگی‌ کنه و یا حتی راهکار جایگزین ارائه بده.

۵- نیروی سنیور توانایی مدیریت نیروهای سطح پایین‌تر رو داره، می‌تونه توی پروژه‌ها، کدها و تصمیمات کمک کنه و مسیر درست رو بهشون نشون بده لیدر و منتور خوب بودن جزو خصیصه‌های نیروی سنیور هست

۶- موارد دیگری هم هست، مثل :
سال‌های تجربه (شاید نه فقط از نظر فنی بلکه از نظر کار تیمی)
نحوه برخورد با مشکلات داخل تیمی (مشکلات غیر فنی)
میزان رشد (سنیور، هیچوقت منتظر نمی‌مونه ازش چیزی بخوان تا پیشرفت کنه و هیچوقت از یادگیری دست بر نمیداره)
میزان پیچیدگی پروژه‌ای که روش کار می‌کنید و ...

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

اما هیچکدوم از موارد بالا، باینری نیست
توی همه موارد من گفتم سنیور ولی اگر شما مثلاً توی همون مثال اول چند مورد رو بلدی و چندتا رو نه، امتیاز کمتر از سنیور میگیری (مثلاً میدیور)

در نهایت بازم میگیم، برای من بهترین تکنیک مصاحبه دادن هست
اما اگر نمی‌تونید مصاحبه بدید، از
Mock interview
استفاده کنید (نهایت اینه که ۲ ساعت دستمزد پرداخت کنید).
فقط تورو خدا نرید هر آدم رندمی که پیدا کردید باهاش مصاحبه کنید (حداقل کمی تجربه مصاحبه گرفتن داشته باشه) یا اینکه روی اون موضوع مسلط باشه منظورم رو با مثال بگم :
فرض کنیم من یک دوستی دارم، مدرس دوره
System Design
ولی تجربه مصاحبه کردن نداره، من پیش ایشون نمیرم بگم بیا من رو تعیین سطح کن ببین استخدام میشم یا خیر چون احتمال زیاد ایشون بایاس هست به سمت تخصص خودش.
اما می‌تونم از ایشون خواهش کنم من رو برای مبحث
System Design
یک مصاحبه تعیین سطح کنه، توی همچین
Mock Interview
قطعاً وقت هیچکدوم سر سوالات حاشیه‌ای نخواهد رفت و فقط ۲-۳ مورد.
تمرین system design خواهیم داشت و اگر من seniority رو از ایشون بگیرم، خیالم روی این مبحث مصاحبه بسیار راحت خواهد بود.

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

هم اعتماد به نفس شمارو خراب ، هم وقت شمارو تلف می‌کنه
فرض کنید توی مصاحبه به شما توی راهنمایی اشتباه بگه که باید سطح advance سوالات leet code رو حل کنید.
در حالی که ممکن دلیل رد شدن شما توی مصاحبه‌های سطح سنیور، عدم توضیح راه‌حل یا عدم توانایی مدیریت تنش و مشکلات و ... باشه.

روی این مورد از من راهکار خواستن (جلوتر مثال میزنم برای توضیح)

همین اول کار بگم یک فرمول ثابت برای همه وجود نداره هرکسی گفت وجود داره کلاش هست .اگر فرمولش ثابت بود؛ برای همه بچه مدرسه‌ای ها و دانشجو‌ها استفاده میکردن که همه بتونند به درستی از تمام ظرفیت هوش و استعدادشون استفاده کنند.

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

کدوم یک از شما تو کدی که باگ و مشکل نداره؛ دنبال تغییر الگوریتم هستید ؟ پس پیدا کردن مشکل خودش ۷۰-۸۰٪ رسیدن به راه‌حل هست.

درنهایت من با این مثال توضیج دادم؛ فکر کردم شاید مفید باشه هرچند یک جلسه لایو ویدئویی می‌تونست بهتر باشه :

مثلا:
فرض کن داکیومنت
FastAPI
رو داری میخونی؛ نمیری بشینی توضیح نحوه نوشته شدن
generator
رو بخونی؛ موارد مهم رو میخونی مثل get, post, route, authentication , ...

یعد میای می‌بینی نوشته
Async
و تو میدونی لازم داری توی تمام پروژه‌هات مهم هست
چیکار می‌کنی از روی دامکیومنت Fastapi میخونی ؟
قطعا نه؛ میری یک کتاب یا یک دوره براش پیدا میکنی که هدفش فقط همین باشه

حالا فرض کن کتاب Async رو میخوای بخونی؛ توی ۳ فصل اول هم مقدمات پایتون هست
میشینی از اول بخونی ؟
نه فقط نگاه به سرفصل میکنی و اگر همرو میشناختی حذف میکنی و از فصل ۴ شروع میکنی

یک مثال دیگه کتاب fluent هست؛ این کتاب و کتابهای مشابه هر فصل یک هدفی داره
شاید داخل یک فصل اومده مثلا فریمورک django رو مثال زده
اینجا بر خلاف مثال قبلی
Async , FastAPI
شما نباید بری django رو بخونی اول به هدف فصل نگاه میکنی مثلا
mixin (multiple inheritance)
هست و بعد سعی میکنی همین رو درک کنی حالا اگر نویسنده کتاب زحمت کشیده ی مثال هم زده و شما بلد نیستی نباید برات مهم باشه

چون اون مثال میشه حاشیه برای شما؛ چون تو اصلا بکند دولوپر نیستی.

Elon musk on X

SpaceX just achieved peak download speed of 17Mb/s from satellite direct to unmodified Samsung Android phone

.

پ.ن :
نمی‌دونم دقت کردید، ولی همین سرعت پایین اینترنتی که ایلان ماسک و ... هم ازش رضایت ندارند.
از سرعت سرورهای برج میلاد هم بیشتره (بهترین سرورهای داخلی، با بیشترین سرعت اینترنت) 🤣😂

#Quick


نوشتن list اطراف هر تابع باید دوبار بهش فکر کنید. اگر اون تابع یک generator باشه شما دارید بدترین کار ممکن رو می‌کنید.

این مورد رو بین بچه‌های دیتاساینس و هوش خیلی زیاد می‌بینم و بین بچه‌های بکند هم وقتی دارند روی CSV, Json و یا Json-line کار می‌کنند.

موضوع فقط مصرف زیاد رم نیست؛ موضوع سرعت هم هست اگر قرار به تمیزکاری و پردازش هر نمونه دپتا یا خط به خط هست لطفا از generator ها به درستی استفاده کنید

مشکل دارن با ما؛ ما اینجا زحمت می‌کشیم generator می‌نویسیم بعد اینا سریع می‌ندازنش توی list

تصویر ی نمونه خیلی ساده برای مثال هست (زمان اجرا کامنت شده)

#تجربه

فریمورک برای یادگیری core python نیست،
سورس کد خوندن برای بهتر شدن هست نه یادگیری.


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

نشسته بودم سفارشم آماده بشه (قهوه نخوردم، چون dark roast داشت فقط) دیدم توی فضایی جداگانه کنار من (مثل بخش vip) یکنفر درحال آموزش دادن
generator, yield, yield from
هست، البته برای دیپ‌ لرنینگ و از روی فریمورک، متوجه شدم خیلی داشت اشتباه توضیح می‌داد.

بعد از چند دقیقه که حواسم به کلاس اونها بود و مدرس حواسش به من، کلاس‌ ۵ دقیقه استراحت داد و متوجه شدم از اون ۱۲-۱۵ نفر ۳-۴ نفر عضو همین کانال هستند و مدرس و باقی اعضا همه رفیق هستند که دارند تلاش می‌کنند باهم یاد بگیرند.

خداییش خیلی خیلی لذت بردم (کامیونیتی اینجوری لذت بخش هست) و توی این بحث و اینکه چطوری data loading, batching, ... توی فریمورک‌های هوش مصنوعی کار‌ می‌کنه مونده بودند و اشتباه این بود که بجای درک مطالب اصلی و عملکردشون سعی داشتند از framework این موضوع رو یاد بگیرند.

چندتاشون سوال پرسیدند و براشون توضیح دادم، بعد دعوت کردن این مبحث رو توی کلاس آموزش بدم.
منم که منتظر تماس بودم، شروع کردم با پایتون کد زدن و آموزش دادن و تأکید کردم این چیزا رو نباید با فریمورک یادگرفت هدف هرچی که باشه

ولی واقعاً دیدن همچین کامیونیتی‌هایی لذت بسیار زیادی داره، یادگیری رایگان و دردسترس برای همه.

یک توضیح کوچک راجب یوتیوب بدم، چون خیلی سوال شد.

قرار بر همکاری با یک video editor بود و خوب هم داشت پیش میرفت
ایده ساخت انیمیشن بود، و بعد از تست دوتا مبحث دیدیم که بهترین کار همین هست چون به خوبی مطالب رو انتقال و نمایش میده

حدوداً ۵ موضوع، ویدئو نزدیک به ۲۰ دقیقه آماده شده بود که متأسفانه ایشون تصمیم گرفت ویدئو‌ها رو به بنده نده و ایده رو خودش ادامه بده و شاید تدریس بکنه.
هرچند حتی اگر اینکار رو بکنه هم من ناراحت نیستم چون هدفم آموزش بود.

به هر حال، دلیل اینکه کانال یوتیوب چیزی آپلود نشده این بود ( پیدا کردن همکار، آموزش کار با انیمیشن، ریکورد و ارسال و تدوین و ....)
بسیار زمان‌بر بود و وقتی هم که ایشون کار رو یاد گرفت تصمیم گرفت که به بنده نده و حتی اگر لازم باشه دوره رو به فروش بذاره.

ایده انیمیشن رو ندارم دیگه (هر ویدئو تقریباً ۲ هفته کار برد)، اما سعی دارم از کد برای ساخت تصاویر استفاده کنم که مفاهیم راحت‌تر منتقل بشه و هر زمان خالی که داشته باشم روی این موضوع کار می‌کنم (یادگیری خودم و ساخت ویدئو)

این یکی واقعاً برام سوال هست،

دوستان سنیور، چطور میشه به یک نیرو منبعی رو معرفی کرد برای
Design Pattern

چیزی که زیاد می‌بینم اینه که خیلی از بچه‌ها، مطالب مربوط به design pattern رو می‌‌دونند و تعاریف و مثال‌ هارو به خوبی از پسشون بر میان (هرچند عمرا نمی‌بینید من تو مصاحبه تعریف چیزی رو بپرسم)

ولی وقتی به کدها نگاه می‌کنیم، تصمیمات اشتباه زیاد دیده میشه
اکثراً هم بعد از یک میت ۱۰ دقیقه طرف متوجه مشکل می‌شه و حتی راه حل درست رو می‌گه


شخصاً هنوز کتاب یا دوره آموزشی ندیدم که
Design Pattern
هارو به خوبی و با چندتا مثال کد توی دنیای واقعی نشون بده.


نرید
Gang of Four
رو برای من بیارید که شرط می‌بندم یکبارم نخوندید 😑

من این مورد رو برای توسعه دهنده‌های پایتون می‌خوام و با مثال واقعی.

به بهانه 4k شدن کانال


I've Got You Under My Skin
Artists: Ben L'Oncle Soul
Album: Under My Skin
Released: 2016
Genres: Classical Soul

#flac

این روش log نوشتن برای پروژه کوچک خوبه که تعداد request کمی هم داره،
برای پروژه بزرگتر یا فریمورک و ابزارهای دیگه اصلا این روش توصیه نمی‌شه

چون امروز با یکی از نیروها بحث شد، قرار شد یک سمپل بهشون بدم
دیدم موضوع مهمی هست مخصوصاً بعد از اینکه به این پست اشاره کردند

گفتم بهتر توی کانال هم بصورت نوشتاری بذارم

سری پست‌های این هفته در مورد logging خواهد بود.

یکی از دوستان زنگ زد؛ میگه نمیشه زودتر بگی داستان چی هست دارم لاگر پروژه شرکت رو می‌نویسم؛
کل منبع صحبت‌های این هفته :
Logging Cookbook, python documentation

این صحبتم که میگن داکیومنت خوبی نداره و ... هرکی گفت بهش بگید : چون درست نخوندی.
اگر شما هم مثل ای رفیق من خواستید زودتر شروع کنید به خوندن؛ توی داکیومنت بالا چندتا log handler رو حتما بهش توجه ویژه کنید.

RotatingFileHandler, QueueHandler

قبلا صحبت شده راجب اولی؛ دومی هم برای multi thread کردن هست که لاگ نویسی باعث کند شدن پردازش نشه.
StreamHandler, SMTPHandler, SocketHandler
توی این ۳ مورد هم مورد اول داخل داکر بدرد بخور هست؛ smpt رو هم احتمالا حدس زدید برای ارسال ایمیل هست (معمولا لاگ‌های critical رو برای خودمون یا ادمین یا ... ارسال می‌کنیم) و در نهایت هم SocketHandler که برای ارسال لاگ با پروتکل tcp به سرور دیگری استفاده میشه که خیلی خیلی مهم هست (باور ندارید از بچه‌های امنیت بپرسید)

معمولا خود من از این ۵ مورد توی پروژه‌های بزرگ استفاده می‌کنم؛ البته خیلی وقتا شرکت‌ها SocketHandler نمیگرین و براساس event یا ساعتی یا ... بکاپ لاگ فایل رو به S3 bucket میفرستند روی آمازون که هزینه کمتری داره برای نگهداری.

#یادم_باشه

حتماً یادم باشه نوشتن
Log filter
کاستوم رو یاد بدم،

شرکت با یکی از شرکت‌های خدمات دهنده اروپایی قرارداد بسته
و برای تست قرار شد، ۱ هفته یک کپی از دیتاهاشون رو بفرستند سمت log server ما.

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

یکی اینجا استفاده از logging رو بلد نبوده 😁


پ.ن : توی پست‌های بعدی آموزش داده شد.

با یک مثال خیلی ساده شروع کنیم تا مطلب جا بیوفته قشنگ؛ توجه کنید من توقع دارم کار با logging رو مقدماتش رو بلد باشید.

اصلی ترین عنصر logger هست؛ اگر بخوام خیلی خلاصه بگم:
وظیفه‌اش اینه که یک پیام از شما دریافت کنه و بر اساس level اون رو به handler درستش ارسال کنه.

با این تعریف عنصر بعدی که راجبش صحبت می‌کنیم handler هست.
وظیفه‌اش ارسال لاگ به مقصدی هست که براش تعریف شده.

اما ۲ مورد دیگه هم وجود داره که استفاده ازش می‌تونه زندگی رو بعدا براتون شیرین کنه:

formatter
اینکه چه اطلاعاتی توی لاگ فایل (علاوه بر پیام شما) بصورت خودکار قرار بگیره و اینکه این اطلاعات چطور نمایش داده بشه همش وظیفه این عزیز دل هست.

filters
وظیفه فیلتر کردن لاگ‌ها رو داره؛ چه اینکه نوشته نشه یا تغییراتی روش انجام بشه و بعد نوشته بشه.

استیج آماده شد؛ بریم سراغ مثال تصویر
استفاده از logging.basicConfig چیزی نیست که برای پروژه‌های مهم و بزرگ بخواید داشته باشید؛ چون معمولا بیش از ۳ مورد handler خواهید داشت که این یعنی تعداد زیادی logger که هرکدوم formatter, filter های خودشون رو خواهند داشت.

ادامه پست بعدی ....

source code

برای همین گزینه بهتر استفاده از logging.config.dictConfig هست؛ این تابع تنظیمات رو بصورت dictionary از شما تحویل میگیره و logger رو برای شما میسازه.
همینجا بگم؛ توی سورس کدهای مختلف ممکن هست که این کانفیگ‌ها (دیکشنری) رو توی فایل‌های json, yaml, ini نوشته باشند؛ اما شخصا موقع نوشتن کد سعی می‌کنم مستقیم اینکار رو انجام بدم (داخل py). دروغ چرا مغزم رو درگیر حفظ کردن کلیدهای دیکشنری نمی‌کنم و اینطوری خود vscode کلیدهای موجود رو بهم میده اما راجب config مثال بالا که خیلی خیلی ساده هم هست.
اول از همه version فعلا فقط 1 وجود داره (ورژن دیگه اومد همدیگر رو خبر می‌کنیم)؛ disable_exisiting_logger اگر True بذارید هر لاگر دیگه‌ای که توی این کانفیگ نیست غیرفعال میشه ۹۹٪ موارد روی False بذارید.
موارد بعدی یعنی filters, formatters رو برای این مثال کاری نداریم (ساده شروع کنیم و کم کم بهش برسیم).
و اما handlers؛ اولین چیزی که براش لازم هست اسمش میشه (باید بدونیم چی صداش کنیم) که توی مثال بالا من اسمش رو گذاشتم console چون قراره لاگ هارو توی ترمینال نمایش بده؛ توی خط بعدی یک کلید داره به اسم 'class' اگر قرار بود از Handler‌هایی که خود ماژول logging یا ماژول‌های دیگه براتون فراهم می‌کنند استفاده کنید از کلیدواژه 'class' استفاده میشه و مقداری که بهش میدید کلاسی از اون ماژول هست و باید قابل import باشه توی این مثال من StreamHandler رو استفاده کردم یعنی شما می‌تونید ی جایی تست کنید :

from logging import StreamHandler

مورد بعدی stream این کلید ثابت نیست؛ دلیلش هم واضح هست (حداقل برای من) هر کلاس یک سری پارامتر ورودی مختص به خودش داره StreamHandler هم توی ورودی می‌تونه یک کلید به اسم stream دریافت کنه که البته optional هست؛ یعنی حتی اگه توی مثال بالا این خط کانفیگ رو پاک کنید بازم کار می‌کنه ولی بصورت دیفالت مقدارش روی sys.stderr تعریف شده که تحت شرایطی ممکنه نخواهید اینطوری باشه پس می‌تونید تغییرش بدید. که من گفتم از ماژول sys و stdout یا همون standard output استفاده کنه و خروجی اینجا نمایش بده ( اگر فرق stdout, stderr رو نمی‌دونید؛ ی ذره لینوکس بخونید )
ولی داستان

ext://

اولش چیه پس ؟ هیجی فقط بهش میگه که این مورد رو از یک ماژول external باید بگیری (لازم بود برو import کن).

در نهایت logger؛ مثل مورد قبل اولین مورد اسم هست این اسم مثل handler دلبخواهی نیست؛ و بهتر اسم بالاترین سطح پوشه‌ای باشه که این لاگر براش تعریف می‌شه؛ من اسم پروژه‌ام رو گذاشتم pyhints و این پوشه رو تبدیل به یک ماژول / پکیج کردم و می‌خوام برای تمام py فایل‌های داخلش از این logger بتونم استفاده کنم. برای همین هم اسم logger ام رو pyhints گذاشتم. توی ساده ترین حالت شما نیاز به دوتا کلید دارید؛ اولیش level که من اینجا گفتم مثلا از یک فایل .env پروژه میخونم (پیاده‌سازیش تمرین برای شما) و اگر توی محیط develop نبودم نمی‌خوام لاگ‌های debug دیده بشه فقط از info به بالا رو قبول کن.
کلید بعدی یعنی handlers لیستی از handler هارو میگیره و اگر یک لاگ مسیج هر دو شرایط رو داشت (هم از پکیج pyhints بود؛ هم level بالاتر از آنچه توی خط قبل تعریف شده داشت) اون موقع اون پیام رو برای handler ها می‌فرسته تا کار درست رو باهاش انجام بدند.

حالا فقط کافیه توی کل پروژه یکبار این تابع صدا زده بشه تا logger ما تنظیمات اختصاصی خودش رو دریافت کنه؛ اتفاقی که توی مثال بالا توی خط 30 داره میوفته.
خط 32 اما خیلی مهمه دارم میگم برو ی لاگر برام بیار اسمش رو بذار pyhints.log_config اینجا به عمد ی همچین اسمی دادم تا نشون بدم چقدر اسمی که برای logger انتخاب می‌کنید مهم هست؛ اما توی کدها و پروژه‌هاتون از __name__ استفاده می‌کنید ( درصورت import همین فرمت اسم رو می‌سازه که من بهش دستی دادم).
اینجا logging نگاه می‌کنه که کانفیگ اختصاصی داریم که logger ایی به اسم pyhints داخلش تعریف شده و ماهم توی درخواست getLogger اسمی دادیم که اگر با . جداسازی بشه pyhints بخش بالاتر هست پس این دو مورد باهم مچ میشه و می‌تونه از این لاگر خاص برای اسکریپت فعلی استفاده کنه حالا متغییر logger از تنظیمات pyhints.logger استفاده خواهد کرد برای نمایش log messages داخل ترمینال.

من سعی کردم خیلی ساده توضیح بدم؛ تا همه این موارد رو متوجه بشوند (این رو درک کنید و البته جایگاه هرکدوم رو) ۷۰٪ کار حله.

امیدوارم مفید باشه. 🌹

نکته بعدی تنظیم formatters هست؛ همیشه سعی می‌کنیم ساده شروع کنیم.
برای مثال توی این کد (ادامه کد قبلی) من یک فرمتر استاندارید اضافه کردم.
همیشه سعی می‌کنم توی فرمترهایی که می‌نویسم چندتا فیلد رو داشته باشم :
1- asctime
اون 10s بغلش برای اینه که میخوام حتما اندازه ۱۰ کاراکتر فضا داشته باشه حداقل توی levelname بهتر خودشو نشون میده
2- levelname
باید بدونیم وضعیت لاگ چطوری هست؛ لاگ debug, info چیزی نیست که روزانه بخواید چشمتون بهش باشه
3- name
برای اینه که بدونیم لاگ از کدوم اسکریپت اومده؛ راحتی خودمون هست.
4- lineno
این مورد رو توی کدهای نیروهام نبینم؛ merge نمیشه
داستان اینه که ترکیب این مورد و اسم فایل من رو دقیقا میبرم روی تابع / متد یا ... ایی که باعث خطا شده.
5- message
اصل جنس هم اینجاس پیامی که باید ارسال بشه
باقی موارد هم برای قشنگیش هست.

اما چرا دروغ؛ شمارو نمیدونم من چشمام اینطوری اذیت میشه یک سری لاگ سفید روی پس زمینه سیاه خوندنش برام سخت هست.