ابتدا موارد لازم برای نوشتن این مقاله رو import و نصب میکنیم.
✔️ از چند جهت میشه این سوال رو بررسی کرد و پاسخ داد.
✅ از نظر آپدیت شدن:
- در stdlib:
کتابخانه‌هایی که وارد استاندارد لایبرری میشن، مجبور هستن که در release schedule عه پایتون قفل بشوند. یعنی برای اضافه کردن فیچر‌های جدید نمیتونن بیرون از release schedule پایتون آپدیت بشن. (البته برای دریافت زودتر بروزرسانی‌هاشون میشه از ورژن‌‌های آلفا و بتا استفاده کرد.)
- در PyPI:
اما کتابخونه‌هایی که در PyPI منتشر می‌شوند می‌توانند release schedule خودشان را به هر صورتی که می‌خواهند داشته باشند. و آزادانه آپدیت بشن.
با یه مثال توضیحش می‌دیم! کتابخونه requests وقتی اومد، خیلی محبوب شد و جامعه، از توسعهدهندههای پایتون خواستن که اون رو بیارن توی stdlib. اما دو مشکل وجود داشت:
۱. وقتی یک لایبرری به stdlib اضافه میشه، باید یک یا چند نفر اون رو نگهداری کنن. که هزینه‌برداره!
۲. علاوه بر مورد قبلی، همون‌طور که گفتیم، دیگه آپدیت شدنش دست خودش نیست و هر آپدیتی که داره، باید صبر کنه تا آپدیت بعدی پایتون. اینجوری سرعت توسعه کم میشه و ویژگی‌های جدیدش دیر به دیر به کتابخونه اضافه میشن! بویژه که اون زمان، کتابخونه requests هم تند تند آپدیت می‌داد و نمی‌تونست اینقدر صبر کنه!
تا اینجا:
stdlib 0️⃣ : 1️⃣ PyPI
➰➰➰➰➰➰➰➰➰➰➰➰➰
✅ سازگاری با ورژن پایتون و داشتن باگ:
- در stdlib:
کتابخانه‌هایی که در stdlib هستن، از نقص‌های بسیار کمی برخوردار هستن و حواس توسعهدهندههای پایتون بهشون هست :) چون از مرحله نوشتن PEP و prototypeهای ساده و طراحی APIهاشون، core developerهای خِبره و زیادی نظراتشون رو به نویسنده (ها) میگن. در ضمن این کتابخونه‌ها همیشه با ورژنی که منتشر میشن سازگاری دارن.
- در PyPI:
اما کتابخونه‌هایی که در PyPI هستن در اغلب موارد بعد از منتشر شدن آخرین ورژن پایتون با اون سازگاری ندارن و باید تغییراتی در سورس‌کد خودشون داشته باشن. از نظر داشتن باگ و کارکرد هم دو حالت دارن:
۱. یا جامعه بزرگ یا چند تا توسعه‌دهنده پرکار پشت‌شون هستن که اون کتابخونه رو ساپورت باگ‌هاشون رو سریع پیدا و فیکس میکن.
۲. یکی دوتا توسعه‌دهنده دارن که این بسته رو فلان سال نوشته‌اند و به حال خودشون رها کردن و ممکنه باگ‌های بسیاری داشته باشن و هیچ‌کس هم پاسخ‌گوشون نیست.
تا اینجا:
stdlib 1️⃣ : 1️⃣ PyPI
➰➰➰➰➰➰➰➰➰➰➰➰➰
✅ پشتیبانی:
در توسعه نرم‌افزار شما باید حواس‌تون به dependencyهای اون نرم‌افزار باشه، هر چقدر برنامه شما بیشتر از بسته‌های مختلف استفاده کنه، ریسک باگ پیدا شدن در اون بیشتر هست. بالاتر گفتیم اصلا شاید یکی از کتابخونه‌هایی که نصب کردید دیگه توسعه پیدا نکنه. به مشکلات جدی بخوره و ... حالا شما دو انتخاب دارید:
۱. خودتون برید اون کتابخونه رو مطالعه کنید و برای نرم‌افزارتون نگهداری کنید.
۲. اون رو حذف کنید و قسمت‌هایی که به اون کتابخونه احتیاج داشتید رو باز نویسی کنید.
پس در دو حالت ضرر کردید.
اما این در مورد stdlib آنچنان صدق نمیکنه؛ چرا؟ چون اولا همین که در stdlib هستن یعنی تا مدت‌های مدیدی قراره کاملا از ساپورت برخوردار باشن. ثانیا همیشه و بدون نصب یه چیز اضافه و فقط با یک import ساده شما بهشون دسترسی دارید. اما این رو هم در نظر داشته باشید که هر چقدر بیشتر از stdlib ایمپورت کنید، dependencyهای شما زیاد شده اما دیگه نگرانی‌های بالا رو نخواهید داشت.
تا اینجا
stdlib: 2️⃣ : 1️⃣ PyPI
➰➰➰➰➰➰➰➰➰➰➰➰➰
✅ یک سری از کتابخونه‌ها با Cython نوشته شده‌اند (برای مثال: uvloop ،httptools و asyncpg و .....) این کتابخونه‌ها نمیتونن به stdlib وارد بشوند؛ چون اگر یک کتابخانه بخواد به stdlib اضافه بشه یا با پایتون باید نوشته شده یا با زبان سی (با استفاده از C API). کاری که سایتون میکنه اینه که شما با سینتکسی بسیار شبیه به پایتون کدی رو می‌نویسید و سایتون میاد و یک کد optimize شده با زبان سی براتون generate میکنه و یک C extension برای شما می‌سازه و شما از خروجی می‌تونید به عنوان یک کتابخونه عادی پایتون استفاده کنید.
خب مشکلش کجاست؟ مشکلش اینه که سایتون هم یک بسته PyPI هست D: اگر بسته‌ای تولید شده از سایتون به stdlib اضافه بشه، اون‌وقت خود پایتون یک dependency خارجی داره و به سایتون احتیاج خواهد داشت.
اگر قرار باشه در آینده بسته‌های تولیدی از سایتون به stdlib اضافه بشن، پایتون اول باید Cython رو درون خودش embed کنه و اون رو در stdlib به رسمیت بشناسه، تا بعدش بتونیم کتابخونه‌های تولیدی سایتون رو به stdlib پایتون اضافه کنیم
تا اینجا:
stdlib 2️⃣ : 2️⃣ PyPI
➰➰➰➰➰➰➰➰➰➰➰➰➰
✅ از نظر general purpose بودن پایتون:
پایتون یک زبان (ران تایم، اکوسیستم و ...) general purpose هست! یعنی روی یک موضوع مشخص تمرکزی نداره؛ اما از جهت دیگر یک زبان batteries included هم هست، یعنی با خودش یک stdlib عه general purpose داره. این استاندارد لایبرری باید یک رنج مختلفی از مشکلات رو بر طرف کنه. برای مثال ما ماژول csv داریم، ماژول json داریم، ماژول ZoneInfo داریم، ماژول tkinter هم داریم.
خب بعضی از لایبرری‌ها به طور خاص روی یک موضوع خاص تمرکز کرده‌اند، برای مثال NumPy. اضافه کردن این لایبرری به پایتون باعث میشه یک کتابخونه بزرگ و عظیم در حوزه Numeric Python به stdlib اضافه بشه که با general purpose بودن آنچنان مرتبط نیست! در ضمن اگر به stdlib اضافه بشه مشکل آپدیت شدن طبق چیزی که بالاتر گفتیم رو داره.
برخی از لایبرری ها بسیار حجیم هستن، اگه قرار بود همه ی این لایببری ها داخل standard library باشن و همراه پایتون بیان حجم فایل دانلودی پایتون بسیار بالا میرفت دیگه ۲۰ الی ۳۰ مگابایت نبود.
بیش از ۹۰٪ پکیج های موجود در PyPI بر پایه‌ی ماژول هایی که داخل standard library هستن نوشته شدن و به نوعی اون رو گسترش دادن. به طور مثال پایتون امکان فرستادن درخواست و گرفتن اون رو با ماژول socket فراهم میکنه و افراد یا گروه های مختلف بر اساس سلیقه انواع framework های تحت وب رو مینویسن.
➿➿➿➿➿➿➿➿➿➿➿➿➿➿➿➿
می‌بینید که از جنبه‌های مختلفی این موضوع رو بررسی کردیم و نمیشه رای قطعی داد که یا این یا اون؛ هر کدوم در جای خودش بهترین عملکرد و ویژگی‌ها رو دارن!
Happy Pythoning :)
