مقدمه

کتابخانه‌ی استاندارد پایتون از یک مجموعه از ماژول‌ها تشکیل شده است. روش‌های زیادی برای تجزیه این مجموعه وجود دارد. اکثر ماژول‌ها به زبان پایتون نوشته شده‌اند، اما برخی به زبان C نوشته شده‌اند. همه می‌توانند به برنامه‌ی شما وارد (import) شوند تا کارکرد اضافه کنند. برخی ماژول‌ها رابط‌هایی فراهم می‌کنند که به طور کامل به پایتون اختصاص دارند، مانند چاپ ردگیری پشته؛ برخی رابط‌هایی فراهم می‌کنند که به سیستم‌عامل‌های خاص اختصاص دارند، مانند دسترسی به سخت‌افزار خاص؛ دیگران رابط‌هایی فراهم می‌کنند که به یک دامنه‌ی برنامه خاص اختصاص دارند، مانند توسعه‌ی وب. برخی ماژول‌ها در همه نسخه‌ها و پورت‌های پایتون موجود هستند؛ برخی دیگر تنها زمانی موجود هستند که سیستم پایه آن‌ها را پشتیبانی یا نیاز داشته باشد؛ و برخی دیگر تنها زمانی موجود هستند که یک گزینه‌ی پیکربندی خاص در زمانی که پایتون کامپایل و نصب شده انتخاب شده باشد.

اگر از ابتدا این راهنما را خواندن آغاز کنید، و وقتی خسته شدید به فصل بعد بروید، شما یک دیدگاه کلی معقول از ماژول‌های موجود و حوزه‌های برنامه که توسط کتابخانه‌ی پایتون پشتیبانی می‌شوند بدست می‌آورید. البته، شما لازم نیست آن را مانند یک رمان بخوانید --- شما همچنین می‌توانید فهرست مطالب را (در ابتدای راهنما) مرور کنید، یا به دنبال یک تابع، ماژول یا واژه خاص در اندیس (در انتها) بگردید. و در نهایت، اگر از یادگیری موضوعات تصادفی لذت می‌برید، یک صفحه تصادفی انتخاب کنید و یک یا دو بخش بخوانید. صرف‌نظر از ترتیبی که شما بخش‌های این راهنما را می‌خوانید، بهتر است ابتدا Built-in functions را بخوانید، زیرا باقی این بخش با شناخت این مواد فرض می‌کند.

همچنین ملاحظه نمائید

توابع و کلاس‌های توکار (که می‌توان بدون یک دستور import از آن‌ها استفاده کرد) در ارجاع توکارهای پایتون توصیف شده‌اند.

نکاتی درباره‌ی دسترس‌پذیری

• یک یادداشت «Availability: Unix» به این معنا است که این تابع معمولاً در سیستم‌های یونیکس یافت می‌شود. این یادداشت هیچ ادعایی درباره‌ی وجود آن در یک سیستم‌عامل خاص نمی‌کند.

• اگر به‌طور جداگانه ذکر نشده باشد، همه‌ی توابعی که «Availability: Unix» را ادعا می‌کنند، در macOS، iOS و Android پشتیبانی می‌شوند؛ همه‌ی آن‌ها بر پایه‌ی یک هسته‌ی Unix مبتنی هستند.

• اگر یک یادداشت دسترس‌پذیری شامل هم حداقل نسخه‌ی هسته و هم حداقل نسخه‌ی libc باشد، هر دو شرط باید برقرار باشند. برای مثال، قابلیتی با یادداشت Availability: Linux >= 3.17 with glibc >= 2.27 هم به Linux 3.17 یا جدیدتر و هم به glibc 2.27 یا جدیدتر نیاز دارد.

سکوهای WebAssembly

سکوهای WebAssembly یعنی wasm32-emscripten (Emscripten) و wasm32-wasi (WASI) زیرمجموعه‌ای از APIهای POSIX را فراهم می‌کنند. ران‌تایم‌های WebAssembly و مرورگرها در محیط سندباکس‌شده قرار دارند و دسترسی محدودی به میزبان و منابع خارجی دارند. هر ماژول از کتابخانه استاندارد پایتون که از فرآیندها، نخ‌بندی، شبکه، سیگنال‌ها یا سایر اشکال ارتباط بین‌فرایندی (IPC) استفاده کند، یا در دسترس نیست یا ممکن است مانند سایر سیستم‌های شبه‌یونیکس کار نکند. توابع مربوط به ورودی/خروجی پرونده، سامانه فایل‌بندی و مجوزهای یونیکس نیز محدود شده‌اند. Emscripten اجازه ورودی/خروجی مسدودکننده را نمی‌دهد. سایر عملیات‌های مسدودکننده مانند sleep() حلقه رویداد مرورگر را مسدود می‌کنند.

ویژگی‌ها و رفتار پایتون در سکوهای WebAssembly به نسخه‌ی Emscripten-SDK یا WASI-SDK، ران‌تایم‌های WASM (مرورگر، NodeJS، wasmtime) و پرچم‌های زمان ساخت پایتون بستگی دارد. WebAssembly، Emscripten و WASI استانداردهای در حال تکامل هستند؛ برخی قابلیت‌ها مانند شبکه‌سازی ممکن است در آینده پشتیبانی شوند.

برای پایتون در مرورگر، کاربران باید Pyodide یا PyScript را در نظر بگیرند. PyScript بر پایه‌ی Pyodide ساخته شده است که خود بر پایه‌ی CPython و Emscripten ساخته شده است. Pyodide دسترسی به APIهای جاوااسکریپت و DOM مرورگرها و همچنین قابلیت‌های محدود شبکه‌ای را با APIهای XMLHttpRequest و Fetch جاوااسکریپت فراهم می‌کند.

• APIهای مرتبط با فرایند در دسترس نیستند یا همیشه با خطا شکست می‌خورند. این شامل APIهایی می‌شود که فرایندهای جدید ایجاد می‌کنند (fork()، execve())، منتظر فرایندها می‌مانند (waitpid())، سیگنال‌ها ارسال می‌کنند (kill())، یا به‌گونه‌ای دیگر با فرایندها تعامل دارند. subprocess قابل ایمپورت است اما کار نمی‌کند.

• ماژول socket در دسترس است، اما محدود است و رفتار متفاوتی نسبت به سایر پلتفرم‌ها دارد. در Emscripten، سوکت‌ها همیشه غیرمسدود هستند و برای پراکسی کردن TCP از طریق WebSockets به کد JavaScript اضافی و کمک‌کننده‌هایی روی سرور نیاز دارند؛ برای اطلاعات بیشتر Emscripten Networking را ببینید. WASI snapshot preview 1 فقط سوکت‌ها را از یک توصیف‌گر پرونده موجود می‌پذیرد.

• برخی توابع stub هستند که یا هیچ کاری انجام نمی‌دهند یا همیشه مقادیر سخت‌کدشده را برمی‌گردانند.

• توابع مربوط به توصیف‌گرهای پرونده، مجوزهای پرونده، مالکیت پرونده و پیوندها محدود هستند و از برخی عملیات پشتیبانی نمی‌کنند. برای مثال، WASI پیوندهای نمادین با نام‌های مطلق پرونده را مجاز نمی‌داند.

سکوهای موبایل

اندروید و iOS، از بیشتر جهات، سیستم‌عامل‌های POSIX هستند. ورودی/خروجی پرونده، مدیریت سوکت و نخ‌بندی همگی همان‌گونه رفتار می‌کنند که در هر سیستم‌عامل POSIX دیگری رفتار می‌کردند. با این حال، چند تفاوت عمده وجود دارد:

• در سکوهای موبایل، پایتون فقط در حالت «تعبیه‌شده» قابل استفاده است. REPL پایتون وجود ندارد و امکان استفاده از پرونده‌های اجرایی جداگانه‌ای مانند python یا pip نیز وجود ندارد. برای افزودن کد پایتون به برنامه موبایل خود، باید از API تعبیه پایتون استفاده کنید. برای جزئیات بیشتر، استفاده از پایتون در اندروید و استفاده از پایتون در iOS را ببینید.

• زیرفرایندها:

  • در اندروید، ایجاد زیرفرایندها ممکن است اما به‌طور رسمی پشتیبانی نمی‌شود. به‌ویژه، اندروید هیچ بخشی از System V IPC API را پشتیبانی نمی‌کند، بنابراین multiprocessing در دسترس نیست.

  • یک اپلیکیشن iOS نمی‌تواند از هیچ شکلی از زیرپردازش (subprocessing)، چندپردازشی (multiprocessing) یا ارتباط بین‌پردازش‌ها استفاده کند. اگر یک اپلیکیشن iOS تلاش کند یک زیرفرایند ایجاد کند، فرایندی که زیرفرایند را ایجاد می‌کند یا قفل می‌شود یا سقوط می‌کند. یک اپلیکیشن iOS هیچ دیدی از سایر اپلیکیشن‌های در حال اجرا ندارد و هیچ توانایی‌ای برای ارتباط با سایر اپلیکیشن‌های در حال اجرا ندارد، مگر از طریق APIهای مخصوص iOS که برای این منظور وجود دارند.

• برنامه‌های موبایل دسترسی محدودی برای تغییر منابع سیستم (مانند ساعت سیستم) دارند. این منابع معمولاً قابل خواندن هستند، اما تلاش برای تغییر آن‌ها معمولاً ناموفق خواهد بود.

• ورودی و خروجی کنسول:

  • در اندروید، stdout و stderr بومی به هیچ چیزی متصل نیستند، بنابراین پایتون جریان‌های خودش را نصب می‌کند که پیام‌ها را به گزارش سیستم تغییر مسیر می‌دهند. این پیام‌ها را می‌توان به‌ترتیب زیر برچسب‌های python.stdout و python.stderr مشاهده کرد.

  • اپلیکیشن‌های iOS مفهوم محدودی از خروجی کنسول دارند. stdout و stderr وجود دارند و محتوای نوشته‌شده در stdout و stderr هنگام اجرا در Xcode در گزارش‌ها قابل مشاهده خواهد بود، اما این محتوا در گزارش سیستم ثبت نخواهد شد. اگر کاربری که اپلیکیشن شما را نصب کرده است، گزارش‌های اپلیکیشن خود را به‌عنوان کمکی برای عیب‌یابی ارائه دهد، آن‌ها شامل هیچ جزئیاتی که در stdout یا stderr نوشته شده باشد نخواهند بود.

  • برنامه‌های موبایل اصلاً هیچ stdin قابل استفاده‌ای ندارند. اگرچه برنامه‌ها می‌توانند یک صفحه‌کلید روی صفحه نمایش دهند، این یک قابلیت نرم‌افزاری است، نه چیزی که به stdin متصل باشد.

    در نتیجه، ماژول‌های پایتون که شامل دستکاری کنسول می‌شوند (مانند curses و readline) در سکوهای موبایل در دسترس نیستند.