مقدمه

The Python standard library consists of a collection of modules. There are many ways to dissect this collection. Most modules are written in Python, but some are written in C. All can be imported into your program to add functionality. Some modules provide interfaces that are highly specific to Python, like printing a stack trace; some provide interfaces that are specific to particular operating systems, such as access to specific hardware; others provide interfaces that are specific to a particular application domain, like web development. Some modules are available in all versions and ports of Python; others are only available when the underlying system supports or requires them; yet others are available only when a particular configuration option was chosen at the time when Python was compiled and installed.

If you start reading this manual from the start, and skip to the next chapter when you get bored, you will get a reasonable overview of the available modules and application areas that are supported by the Python library. Of course, you don't have to read it like a novel --- you can also browse the table of contents (in front of the manual), or look for a specific function, module or term in the index (in the back). And finally, if you enjoy learning about random subjects, you choose a random page and read a section or two. Regardless of the order in which you read the sections of this manual, it helps to first read Built-in Functions, as the remainder of this section assumes familiarity with this material.

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

The built-in functions and classes (which can be used without an import statement) are described in Python built-ins reference.

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

• یک یادداشت «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) در سکوهای موبایل در دسترس نیستند.