Introduktion

”Python-biblioteket” innehåller flera olika typer av komponenter.

Den innehåller datatyper som normalt skulle betraktas som en del av ”kärnan” i ett språk, till exempel tal och listor. För dessa typer definierar Pythons språkkärna formen av literaler och lägger vissa begränsningar på deras semantik, men definierar inte semantiken fullt ut. (Å andra sidan definierar språkkärnan syntaktiska egenskaper som stavning och prioriteringar av operatorer)

Biblioteket innehåller också inbyggda funktioner och undantag — objekt som kan användas av all Python-kod utan att det behövs en import-sats. Vissa av dessa definieras av kärnspråket, men många är inte väsentliga för kärnans semantik och beskrivs bara här.

Huvuddelen av biblioteket består dock av en samling moduler. Det finns många sätt att dissekera denna samling. Vissa moduler är skrivna i C och inbyggda i Python-tolken; andra är skrivna i Python och importerade i källform. Vissa moduler tillhandahåller gränssnitt som är mycket specifika för Python, som att skriva ut en stack trace; vissa tillhandahåller gränssnitt som är specifika för vissa operativsystem, som tillgång till viss maskinvara; andra tillhandahåller gränssnitt som är specifika för en viss applikationsdomän, som World Wide Web. Vissa moduler är tillgängliga i alla versioner och portar av Python, andra är endast tillgängliga när det underliggande systemet stöder eller kräver dem, och ytterligare andra är endast tillgängliga när ett visst konfigurationsalternativ valdes vid den tidpunkt då Python kompilerades och installerades.

Den här handboken är organiserad ”inifrån och ut”: först beskrivs de inbyggda funktionerna, datatyperna och undantagen, och slutligen modulerna, grupperade i kapitel med relaterade moduler.

Det betyder att om du börjar läsa den här manualen från början och hoppar till nästa kapitel när du blir uttråkad, kommer du att få en rimlig översikt över de tillgängliga moduler och applikationsområden som stöds av Python-biblioteket. Naturligtvis behöver du inte läsa den som en roman — du kan också bläddra i innehållsförteckningen (längst fram i handboken) eller leta efter en specifik funktion, modul eller term i indexet (längst bak). Och slutligen, om du tycker om att lära dig om slumpmässiga ämnen, kan du välja ett slumpmässigt sidnummer (se modulen random) och läsa ett avsnitt eller två. Oavsett i vilken ordning du läser avsnitten i den här handboken är det bra att börja med kapitel Inbyggda funktioner, eftersom resten av handboken förutsätter att du är bekant med detta material.

Låt showen börja!

Anmärkningar om tillgänglighet

• En ”Tillgänglighet: Unix” betyder att den här funktionen är vanligt förekommande på Unix-system. Den gör inga påståenden om att den finns på ett visst operativsystem.

• Om inte annat anges särskilt, stöds alla funktioner som anger ”Availability: Unix” stöds av macOS, iOS och Android, som alla bygger på en Unix-kärna.

• Om en tillgänglighetsinformation innehåller både en minsta kärnversion och en minsta libc-version, måste båda villkoren uppfyllas. Till exempel en funktion med anmärkningen Availability: Linux >= 3.17 med glibc >= 2.27 kräver både Linux 3.17 eller nyare och glibc 2.27 eller nyare.

WebAssembly-plattformar

WebAssembly-plattformarna wasm32-emscripten (Emscripten) och wasm32-wasi (WASI) tillhandahåller en delmängd av POSIX API:er. WebAssembly-körningar och webbläsare är sandboxade och har begränsad åtkomst till värden och externa resurser. Alla moduler i Pythons standardbibliotek som använder processer, trådning, nätverk, signaler eller andra former av kommunikation mellan processer (IPC) är antingen inte tillgängliga eller fungerar kanske inte som på andra Unix-liknande system. Fil-I/O, filsystem och Unix-behörighetsrelaterade funktioner är också begränsade. Emscripten tillåter inte blockerande I/O. Andra blockeringsoperationer som sleep() blockerar webbläsarens händelseslinga.

Pythons egenskaper och beteende på WebAssembly-plattformar beror på Emscripten-SDK- eller WASI-SDK-versionen, WASM-runtimes (webbläsare, NodeJS, wasmtime) och Pythons byggtidsflaggor. WebAssembly, Emscripten och WASI är standarder under utveckling; vissa funktioner, t.ex. nätverk, kan komma att stödjas i framtiden.

För Python i webbläsaren bör användarna överväga Pyodide eller PyScript. PyScript är byggt ovanpå Pyodide, som i sin tur är byggt ovanpå CPython och Emscripten. Pyodide ger tillgång till webbläsarnas JavaScript och DOM API:er samt begränsade nätverksfunktioner med JavaScript:s XMLHttpRequest och Fetch API:er.

• Processrelaterade API:er är inte tillgängliga eller misslyckas alltid med ett fel. Det inkluderar API:er som skapar nya processer (fork(), execve()), väntar på processer (waitpid()), skickar signaler (kill()) eller på annat sätt interagerar med processer. Modulen subprocess är importerbar men fungerar inte.

• Modulen socket finns tillgänglig, men den är begränsad och beter sig annorlunda än på andra plattformar. På Emscripten är sockets alltid icke-blockerande och kräver ytterligare JavaScript-kod och hjälpare på servern för att proxy TCP genom WebSockets; se Emscripten Networking för mer information. WASI snapshot preview 1 tillåter endast sockets från en befintlig filbeskrivare.

• Vissa funktioner är stubbar som antingen inte gör någonting och alltid returnerar hårdkodade värden.

• Funktioner relaterade till filbeskrivningar, filbehörigheter, filägande och länkar är begränsade och stöder inte vissa operationer. WASI tillåter t.ex. inte symlinks med absoluta filnamn.

Mobila plattformar

Android och iOS är i de flesta avseenden POSIX-operativsystem. Fil-I/O, socket-hantering och trådning fungerar på samma sätt som i alla POSIX-operativsystem. Det finns dock flera stora skillnader:

• Mobila plattformar kan bara använda Python i ”inbäddat” läge. Det finns ingen Python REPL och ingen möjlighet att använda separata körbara filer som python eller pip. Om du vill lägga till Python-kod i din mobilapp måste du använda Python embedding API. För mer information, se Använda Python på Android och Använda Python på iOS.

• Underprocesser:

  • På Android är det möjligt att skapa underprocesser, men det stöds inte officiellt. I synnerhet stöder Android inte någon del av System V IPC API, så multiprocessing är inte tillgängligt.

  • En iOS-app kan inte använda någon form av subprocessing, multiprocessing eller kommunikation mellan processer. Om en iOS-app försöker skapa en subprocess kommer den process som skapar subprocessen antingen att låsas eller krascha. En iOS-app har ingen insyn i andra applikationer som körs eller någon möjlighet att kommunicera med andra applikationer som körs, utöver de iOS-specifika API:er som finns för detta ändamål.

• Mobilappar har begränsad tillgång till att modifiera systemresurser (t.ex. systemklockan). Dessa resurser är ofta läsbara, men försök att ändra dessa resurser misslyckas vanligtvis.

• Konsolens in- och utmatning:

  • På Android är de inbyggda stdout och stderr inte kopplade till någonting, så Python installerar sina egna strömmar som omdirigerar meddelanden till systemloggen. Dessa kan ses under taggarna python.stdout respektive python.stderr.

  • iOS-appar har ett begränsat koncept för konsolutmatning. stdout och stderr existerar, och innehåll som skrivs till stdout och stderr kommer att synas i loggar när de körs i Xcode, men detta innehåll kommer inte att registreras i systemloggen. Om en användare som har installerat din app tillhandahåller sina apploggar som ett diagnostiskt hjälpmedel kommer de inte att innehålla några detaljer som skrivits till stdout eller stderr.

  • Mobilappar har ingen användbar stdin överhuvudtaget. Även om appar kan visa ett tangentbord på skärmen är detta en programvarufunktion, inte något som är kopplat till stdin.

    Därför är Python-moduler som innebär konsolmanipulation (t.ex. curses och readline) inte tillgängliga på mobila plattformar.