`importlib` — Implementeringen av `import`¶

Tillagd i version 3.1.

Introduktion¶

Syftet med importlib-paketet är trefaldigt.

En är att tillhandahålla implementeringen av import-satsen (och därmed, i förlängningen, __import__()-funktionen) i Python-källkod. Detta ger en implementering av import som är portabel till alla Python-tolkar. Detta ger också en implementering som är lättare att förstå än en implementering i ett annat programmeringsspråk än Python.

För det andra exponeras komponenterna för att implementera import i detta paket, vilket gör det lättare för användare att skapa sina egna anpassade objekt (allmänt kända som en importer) för att delta i importprocessen.

Tre, paketet innehåller moduler som exponerar ytterligare funktionalitet för att hantera aspekter av Python-paket:

importlib.metadata ger tillgång till metadata från tredjepartsdistributioner.
importlib.resources tillhandahåller rutiner för att komma åt icke-kodade ”resurser” från Python-paket.

Se även

Nyckelordet: !import-satsen: Språkreferensen för import-satsen.
Paketspecifikation: Ursprunglig specifikation av paket. Viss semantik har ändrats sedan detta dokument skrevs (t.ex. omdirigering baserad på None i sys.modules).
Funktionen __import__(): Satsen import är ett syntaktiskt socker för denna funktion.
Initialisering av sökvägen för modulen sys.path: Initialisering av sys.path.
PEP 235: Import på plattformar som är okänsliga för skiftlägeslägeskoder
PEP 263: Definiera kodning av Python-källkod
PEP 302: Hooks för ny import
PEP 328: Import: Multi-Line och Absolut/Relativ
PEP 366: Huvudmodulens explicita relativa import
PEP 420: Implicita namnrymdspaket
PEP 451: En ModuleSpec-typ för importsystemet
PEP 488: Eliminering av PYO-filer
PEP 489: Initialisering av utökningsmodul i flera faser
PEP 552: Deterministisk pycs
PEP 3120: Använda UTF-8 som standardkodning för källkod
PEP 3147: Kataloger för PYC-förvar

Funktioner¶

importlib.__import__(name, globals=None, locals=None, fromlist=(), level=0)¶: En implementation av den inbyggda funktionen __import__().

Anteckning

Programmatisk import av moduler bör använda import_module() istället för denna funktion.

importlib.import_module(name, package=None)¶

Importera en modul. Argumentet name anger vilken modul som ska importeras i absoluta eller relativa termer (t.ex. antingen pkg.mod eller ..mod). Om namnet anges i relativa termer måste argumentet package sättas till namnet på det paket som ska fungera som ankare för att lösa upp paketnamnet (t.ex. import_module('..mod', 'pkg.subpkg') importerar pkg.mod).

Funktionen import_module() fungerar som ett förenklande hölje runt importlib.__import__(). Detta innebär att all semantik i funktionen härleds från importlib.__import__(). Den viktigaste skillnaden mellan dessa två funktioner är att import_module() returnerar det angivna paketet eller modulen (t.ex. pkg.mod), medan __import__() returnerar paketet eller modulen på högsta nivån (t.ex. pkg).

Om du dynamiskt importerar en modul som skapats sedan tolken började exekvera (t.ex. skapade en Python-källfil), kan du behöva anropa invalidate_caches() för att den nya modulen ska uppmärksammas av importsystemet.

Ändrad i version 3.3: Föräldrapaket importeras automatiskt.

importlib.invalidate_caches()¶: Invalidera de interna cacherna för sökare som lagras på sys.meta_path. Om en sökare implementerar invalidate_caches() kommer den att anropas för att utföra invalideringen. Den här funktionen bör anropas om moduler skapas/installeras medan ditt program körs för att garantera att alla sökare märker att den nya modulen finns.

Tillagd i version 3.3.

Ändrad i version 3.10: Namnrymdspaket som skapats/installerats på en annan sys.path-plats efter att samma namnrymd redan importerats uppmärksammas.

importlib.reload(module)¶

Laddar om en tidigare importerad modul. Argumentet måste vara ett modulobjekt, så det måste ha importerats tidigare. Detta är användbart om du har redigerat modulens källfil med en extern editor och vill prova den nya versionen utan att lämna Python-tolken. Returvärdet är modulobjektet (som kan vara annorlunda om en ny import gör att ett annat objekt placeras i sys.modules).

När reload() utförs:

Python-modulens kod kompileras om och koden på modulnivå exekveras på nytt, vilket definierar en ny uppsättning objekt som är bundna till namn i modulens ordbok genom att återanvända loader som ursprungligen laddade modulen. Funktionen init för tilläggsmoduler anropas inte en andra gång.
Som med alla andra objekt i Python återkrävs de gamla objekten först när deras referensantal sjunkit till noll.
Namnen i modulens namnrymd uppdateras för att peka på alla nya eller ändrade objekt.
Andra referenser till de gamla objekten (t.ex. namn utanför modulen) är inte rebound för att referera till de nya objekten och måste uppdateras i varje namnrymd där de förekommer om så önskas.

Det finns ett antal andra förbehåll:

När en modul laddas om behålls dess dictionary (som innehåller modulens globala variabler). Omdefinitioner av namn kommer att åsidosätta de gamla definitionerna, så detta är i allmänhet inget problem. Om den nya versionen av en modul inte definierar ett namn som definierades i den gamla versionen, kvarstår den gamla definitionen. Denna funktion kan användas till modulens fördel om den upprätthåller en global tabell eller cache av objekt — med en try-sats kan den testa om tabellen finns och hoppa över dess initialisering om så önskas:

försök:
    cache
except NamnFel:
    cache = {}

Det är i allmänhet inte särskilt användbart att ladda om inbyggda eller dynamiskt laddade moduler. Att ladda om sys, __main__, builtins och andra nyckelmoduler rekommenderas inte. I många fall är tilläggsmoduler inte utformade för att initieras mer än en gång, och kan misslyckas på godtyckliga sätt när de laddas om.

Om en modul importerar objekt från en annan modul med hjälp av from … import …, omdefinieras inte de objekt som importerats från den andra modulen genom att anropa reload() för den andra modulen — ett sätt att komma runt detta är att utföra from-satsen igen, ett annat är att använda import och kvalificerade namn (module.name) istället.

Om en modul instansierar instanser av en klass påverkas inte metoddefinitionerna för instanserna av att modulen som definierar klassen laddas om - de fortsätter att använda den gamla klassdefinitionen. Samma sak gäller för härledda klasser.

Tillagd i version 3.4.

Ändrad i version 3.7: ModuleNotFoundError uppstår när den modul som laddas om saknar en ModuleSpec.

Varning

Denna funktion är inte trådsäker. Om den anropas från flera trådar kan det leda till oväntat beteende. Vi rekommenderar att du använder threading.Lock eller andra synkroniseringsprimitiver för trådsäker omladdning av moduler.

`importlib.abc` – Abstrakta basklasser relaterade till import¶

Källkod: Lib/importlib/abc.py

Modulen importlib.abc innehåller alla de centrala abstrakta basklasser som används av import. Vissa subklasser av de centrala abstrakta basklasserna tillhandahålls också för att hjälpa till att implementera de centrala ABC.

ABC-hierarkin:

objekt
 +-- MetaPathFinder
 +-- PathEntryFinder
 +-- Laddare
      +-- ResourceLoader --------+
      +-- InspectLoader --+ InspectLoader
           +-- ExecutionLoader --+
                                 +-- FileLoader
                                 +-- SourceLoader

class importlib.abc.MetaPathFinder¶

En abstrakt basklass som representerar en meta path finder.

Tillagd i version 3.3.

Ändrad i version 3.10: Inte längre en underklass till Finder.

find_spec(fullname, path, target=None)¶: En abstrakt metod för att hitta en spec för den angivna modulen. Om detta är en import på toppnivå kommer path att vara None. Annars är detta en sökning efter ett underpaket eller en modul och path kommer att vara värdet på __path__ från det överordnade paketet. Om en specifikation inte kan hittas returneras None. När target skickas in är det ett modulobjekt som sökaren kan använda för att göra en mer kvalificerad gissning om vilken specifikation som ska returneras. importlib.util.spec_from_loader() kan vara användbart för att implementera konkreta MetaPathFinders.

Tillagd i version 3.4.

invalidate_caches()¶: En valfri metod som, när den anropas, ska ogiltigförklara alla interna cacheminnen som används av sökaren. Används av importlib.invalidate_caches() när cachen för alla sökare på sys.meta_path ogiltigförklaras.

Ändrad i version 3.4: Returnerar None när den anropas istället för NotImplemented.

class importlib.abc.PathEntryFinder¶

En abstrakt basklass som representerar en path entry finder. Även om den har vissa likheter med MetaPathFinder, är PathEntryFinder endast avsedd att användas inom det sökvägsbaserade importundersystem som tillhandahålls av importlib.machinery.PathFinder.

Tillagd i version 3.3.

Ändrad i version 3.10: Inte längre en underklass till Finder.

find_spec(fullname, target=None)¶: En abstrakt metod för att hitta en spec för den angivna modulen. Sökaren kommer att söka efter modulen endast inom path entry som den är tilldelad. Om en specifikation inte kan hittas returneras None. När target skickas in är det ett modulobjekt som sökaren kan använda för att göra en mer kvalificerad gissning om vilken spec som ska returneras. importlib.util.spec_from_loader() kan vara användbar för att implementera konkreta PathEntryFinders.

Tillagd i version 3.4.

invalidate_caches()¶: En valfri metod som, när den anropas, ska ogiltigförklara alla interna cacheminnen som används av sökaren. Används av importlib.machinery.PathFinder.invalidate_caches() när cacheminnet för alla cachade sökare ogiltigförklaras.

class importlib.abc.Loader¶

En abstrakt basklass för en loader. Se PEP 302 för den exakta definitionen av en laddare.

Laddare som vill stödja resursläsning bör implementera en get_resource_reader()-metod som specificeras av importlib.resources.abc.ResourceReader.

Ändrad i version 3.7: Införde den valfria metoden get_resource_reader().

create_module(spec)¶: En metod som returnerar det modulobjekt som ska användas vid import av en modul. Denna metod kan returnera None, vilket indikerar att standard semantik för modulskapande ska användas.

Tillagd i version 3.4.

Ändrad i version 3.6: Denna metod är inte längre valfri när exec_module() är definierad.

exec_module(module)¶: En abstrakt metod som exekverar modulen i dess eget namnrymd när en modul importeras eller laddas om. Modulen bör redan vara initialiserad när exec_module() anropas. När den här metoden finns måste create_module() definieras.

Tillagd i version 3.4.

Ändrad i version 3.6: create_module() måste också definieras.

load_module(fullname)¶

En äldre metod för att ladda en modul. Om modulen inte kan läsas in visas ImportError, annars returneras den inlästa modulen.

Om den begärda modulen redan finns i sys.modules, bör den modulen användas och laddas om. I annat fall bör laddaren skapa en ny modul och infoga den i sys.modules innan någon laddning påbörjas, för att förhindra rekursion från importen. Om laddaren har infogat en modul och laddningen misslyckas, måste laddaren ta bort den från sys.modules; moduler som redan fanns i sys.modules innan laddaren började exekvera bör lämnas ifred.

Laddaren ska ange flera attribut för modulen (observera att vissa av dessa attribut kan ändras när en modul laddas om):

modul.__name__
module.__file__
modul.__cached__ (föråldrad)
modul.__path__
modul.__package__ (föråldrad)
modul.__loader__ (föråldrad)

När exec_module() är tillgänglig tillhandahålls bakåtkompatibel funktionalitet.

Ändrad i version 3.4: Utlöser ImportError när den anropas istället för NotImplementedError. Funktionalitet som tillhandahålls när exec_module() är tillgänglig.

Deprecated since version 3.4, will be removed in version 3.15: Det rekommenderade API:et för att ladda en modul är exec_module() (och create_module()). Laddare bör implementera det istället för load_module(). Importmaskineriet tar hand om alla andra ansvarsområden för load_module() när exec_module() är implementerat.

class importlib.abc.ResourceLoader¶

Ersatt av TraversableResources

En abstrakt basklass för en loader som implementerar det valfria PEP 302-protokollet för laddning av godtyckliga resurser från lagringsbackenden.

Föråldrad sedan version 3.7: Denna ABC är föråldrad och ersätts av stöd för resursladdning via importlib.resources.abc.TraversableResources. Denna klass finns endast för bakåtkompatibilitet med andra ABC:er i detta modul.

abstractmethod get_data(path)¶

En abstrakt metod för att returnera byte för data som finns på path. Laddare som har en filliknande lagringsbackend som tillåter lagring av godtyckliga data kan implementera denna abstrakta metod för att ge direkt tillgång till de data som lagras. OSError ska tas upp om path inte kan hittas. Sökvägen förväntas vara konstruerad med hjälp av en moduls attribut __file__ eller ett objekt från ett pakets __path__.

Ändrad i version 3.4: Utlöser OSError istället för NotImplementedError.

class importlib.abc.InspectLoader¶

En abstrakt basklass för en loader som implementerar det valfria PEP 302-protokollet för laddare som inspekterar moduler.

get_code(fullname)¶: Returnerar kodobjektet för en modul, eller None om modulen inte har något kodobjekt (vilket t.ex. skulle vara fallet för en inbyggd modul). Ger ett ImportError om laddaren inte kan hitta den begärda modulen.

Anteckning

Metoden har en standardimplementering, men det rekommenderas att den åsidosätts om det är möjligt av prestandaskäl.

Ändrad i version 3.4: Inte längre abstrakt och en konkret implementering tillhandahålls.

abstractmethod get_source(fullname)¶: En abstrakt metod för att returnera källan till en modul. Den returneras som en textsträng med universal newlines, som översätter alla erkända radavgränsare till '\n'-tecken. Returnerar None om ingen källa är tillgänglig (t.ex. en inbyggd modul). Utlöser ImportError om laddaren inte kan hitta den angivna modulen.

Ändrad i version 3.4: Utlöser ImportError istället för NotImplementedError.

is_package(fullname)¶: En valfri metod som returnerar ett sant värde om modulen är ett paket, annars ett falskt värde. ImportError uppstår om loader inte kan hitta modulen.

Ändrad i version 3.4: Utlöser ImportError istället för NotImplementedError.

static source_to_code(data, path='<string>')¶

Skapa ett kodobjekt från Python-källan.

Argumentet data kan vara vad som helst som compile()-funktionen stöder (t.ex. sträng eller byte). Argumentet path bör vara ”sökvägen” till den plats där källkoden kommer ifrån, vilket kan vara ett abstrakt koncept (t.ex. plats i en zip-fil).

Med det efterföljande kodobjektet kan man exekvera det i en modul genom att köra exec(code, module.__dict__).

Tillagd i version 3.4.

Ändrad i version 3.5: Gjorde metoden statisk.

exec_module(module)¶: Implementering av Loader.exec_module().

Tillagd i version 3.4.

load_module(fullname)¶: Implementering av Loader.load_module().

Deprecated since version 3.4, will be removed in version 3.15: använd exec_module() istället.

class importlib.abc.ExecutionLoader¶

En abstrakt basklass som ärver från InspectLoader som, när den implementeras, hjälper en modul att exekveras som ett skript. ABC representerar ett valfritt PEP 302 protokoll.

abstractmethod get_filename(fullname)¶: En abstrakt metod som returnerar värdet av __file__ för den angivna modulen. Om ingen sökväg är tillgänglig, ImportError.

Om källkod finns tillgänglig ska metoden returnera sökvägen till källfilen, oavsett om en bytecode användes för att ladda modulen.

Ändrad i version 3.4: Utlöser ImportError istället för NotImplementedError.

class importlib.abc.FileLoader(fullname, path)¶

En abstrakt basklass som ärver från ResourceLoader och ExecutionLoader och ger konkreta implementationer av ResourceLoader.get_data() och ExecutionLoader.get_filename().

Argumentet fullname är ett fullständigt upplöst namn på den modul som laddaren ska hantera. Argumentet path är sökvägen till filen för modulen.

Tillagd i version 3.3.

name¶: Namnet på den modul som laddaren kan hantera.

path¶: Sökväg till filen för modulen.

load_module(fullname)¶: Anropar super’s load_module().

Deprecated since version 3.4, will be removed in version 3.15: Använd Loader.exec_module() istället.

abstractmethod get_filename(fullname)¶: Returnerar path.

abstractmethod get_data(path)¶: Läser sökväg som en binär fil och returnerar byte från den.

class importlib.abc.SourceLoader¶

En abstrakt basklass för att implementera laddning av källfiler (och eventuellt bytekoder). Klassen ärver från både ResourceLoader och ExecutionLoader, och kräver implementering av:

ResourceLoader.get_data()
ExecutionLoader.get_filename()
Ska endast returnera sökvägen till källfilen; laddning utan källa stöds inte.

De abstrakta metoder som definieras av denna klass är till för att lägga till valfritt stöd för bytecode-filer. Om dessa valfria metoder inte implementeras (eller om de ger upphov till NotImplementedError) fungerar laddaren endast med källkod. Genom att implementera metoderna kan laddaren arbeta med källkods- och bytecode-filer; det tillåter inte källkodslös laddning där endast bytecode tillhandahålls. Bytecode-filer är en optimering för att påskynda laddningen genom att ta bort parsningssteget i Pythons kompilator, och därför exponeras inget bytecode-specifikt API.

path_stats(path)¶

Valfri abstrakt metod som returnerar en dict som innehåller metadata om den angivna sökvägen. Nycklar i ordlistan som stöds är:

'mtime' (mandatory): ett heltal eller flyttal som anger modifieringstiden för källkoden;
'size' (valfritt): storleken i bytes på källkoden.

Alla andra nycklar i ordlistan ignoreras för att möjliggöra framtida tillägg. Om sökvägen inte kan hanteras genereras OSError.

Tillagd i version 3.3.

Ändrad i version 3.4: Utlös OSError istället för NotImplementedError.

path_mtime(path)¶: Valfri abstrakt metod som returnerar modifieringstiden för den angivna sökvägen.

Föråldrad sedan version 3.3: Den här metoden är utfasad till förmån för path_stats(). Du behöver inte implementera den, men den är fortfarande tillgänglig för kompatibilitetsändamål. Utlöser OSError om sökvägen inte kan hanteras.

Ändrad i version 3.4: Utlös OSError istället för NotImplementedError.

set_data(path, data)¶

Valfri abstrakt metod som skriver de angivna bytena till en filsökväg. Eventuella mellanliggande kataloger som inte finns ska skapas automatiskt.

Om det inte går att skriva till sökvägen eftersom sökvägen är skrivskyddad (errno.EACCES/PermissionError), ska undantaget inte spridas.

Ändrad i version 3.4: Ger inte längre upphov till NotImplementedError när den anropas.

get_code(fullname)¶: Konkret implementation av InspectLoader.get_code().

exec_module(module)¶: Konkret implementering av Loader.exec_module().

Tillagd i version 3.4.

load_module(fullname)¶: Konkret implementation av Loader.load_module().

Deprecated since version 3.4, will be removed in version 3.15: Använd exec_module() istället.

get_source(fullname)¶: Konkret implementation av InspectLoader.get_source().

is_package(fullname)¶: Konkret implementation av InspectLoader.is_package(). En modul anses vara ett paket om dess filsökväg (som tillhandahålls av ExecutionLoader.get_filename()) är en fil med namnet __init__ när filtillägget är borttaget och modulnamnet i sig inte slutar på __init__.

class importlib.abc.ResourceReader¶

Ersatt av TraversableResources

En abstract base class för att ge möjlighet att läsa resources.

I det här ABC:s perspektiv är en resurs en binär artefakt som levereras i ett paket. Vanligtvis är detta något som en datafil som lever bredvid paketets __init__.py-fil. Syftet med den här klassen är att hjälpa till att abstrahera åtkomsten till sådana datafiler så att det inte spelar någon roll om paketet och dess datafil(er) lagras t.ex. i en zip-fil eller i filsystemet.

För alla metoder i denna klass förväntas ett resource-argument vara ett path-like object som konceptuellt bara representerar ett filnamn. Detta innebär att inga sökvägar till underkataloger bör inkluderas i resource-argumentet. Detta beror på att platsen för det paket som läsaren är avsedd för fungerar som ”katalog”. Därför är metaforen för kataloger och filnamn paket respektive resurser. Det är också därför som instanser av denna klass förväntas vara direkt korrelerade till ett specifikt paket (i stället för att potentiellt representera flera paket eller en modul).

Laddare som vill stödja resursläsning förväntas tillhandahålla en metod som heter get_resource_reader(fullname) som returnerar ett objekt som implementerar detta ABC-gränssnitt. Om den modul som anges av fullname inte är ett paket, bör denna metod returnera None. Ett objekt som är kompatibelt med denna ABC bör endast returneras när den angivna modulen är ett paket.

Tillagd i version 3.7.

Deprecated since version 3.12, removed in version 3.14: Använd importlib.resources.abc.TraversableResources istället.

abstractmethod open_resource(resource)¶: Returnerar ett öppnat, filliknande objekt för binär läsning av resursen.

Om resursen inte kan hittas genereras FileNotFoundError.

abstractmethod resource_path(resource)¶: Returnerar filsystemets sökväg till resursen.

Om resursen inte finns i filsystemet, uppstår FileNotFoundError.

abstractmethod is_resource(name)¶: Returnerar True om namnet name anses vara en resurs. FileNotFoundError uppstår om name inte finns.

abstractmethod contents()¶: Returnerar en iterable av strängar över innehållet i paketet. Observera att det inte är nödvändigt att alla namn som returneras av iteratorn är faktiska resurser, t.ex. är det acceptabelt att returnera namn för vilka is_resource() skulle vara false.

Att tillåta att icke-resursnamn returneras är för att möjliggöra situationer där det på förhand är känt hur ett paket och dess resurser lagras och icke-resursnamnen skulle vara användbara. Det är t.ex. tillåtet att returnera namn på underkataloger så att dessa namn på underkataloger kan användas direkt när det är känt att paketet och resurserna lagras i filsystemet.

Den abstrakta metoden returnerar en iterabel utan objekt.

class importlib.abc.Traversable¶

Ett objekt med en delmängd av pathlib.Path-metoder som lämpar sig för genomgång av kataloger och öppning av filer.

För en representation av objektet i filsystemet, använd importlib.resources.as_file().

Tillagd i version 3.9.

Deprecated since version 3.12, removed in version 3.14: Använd importlib.resources.abc.Traversable istället.

name¶: Abstrakt. Basnamnet för detta objekt utan några överordnade referenser.

abstractmethod iterdir()¶: Avkastar Traversable-objekt i self.

abstractmethod is_dir()¶: Returnerar True om self är en katalog.

abstractmethod is_file()¶: Returnerar True om self är en fil.

abstractmethod joinpath(child)¶: Returnera Traversibelt barn i self.

abstractmethod __truediv__(child)¶: Returnera Traversable barn i self.

abstractmethod open(mode='r', *args, **kwargs)¶

mode kan vara ’r’ eller ’rb’ för att öppna som text eller binär. Returnerar ett handtag som är lämpligt för läsning (samma som pathlib.Path.open).

När den öppnas som text accepteras kodningsparametrar som de som accepteras av io.TextIOWrapper.

read_bytes()¶: Läs innehållet i själv som bytes.

read_text(encoding=None)¶: Läs innehållet i själv som text.

class importlib.abc.TraversableResources¶

En abstrakt basklass för resursläsare som kan hantera importlib.resources.files()-gränssnittet. Underklassar importlib.resources.abc.ResourceReader och tillhandahåller konkreta implementationer av importlib.resources.abc.ResourceReaders abstrakta metoder. Därför tillhandahåller alla laddare som tillhandahåller importlib.abc.TraversableResources också ResourceReader.

Laddare som vill stödja resursläsning förväntas implementera detta gränssnitt.

Tillagd i version 3.9.

Deprecated since version 3.12, removed in version 3.14: Använd importlib.resources.abc.TraversableResources istället.

abstractmethod files()¶: Returnerar ett importlib.resources.abc.Traversable-objekt för det laddade paketet.

`importlib.machinery` – Importörer och sökvägs-hooks¶

Källkod: Lib/importlib/machinery.py

Denna modul innehåller de olika objekt som hjälper import att hitta och ladda moduler.

importlib.machinery.SOURCE_SUFFIXES¶: En lista med strängar som representerar de identifierade filsuffixen för källmoduler.

Tillagd i version 3.3.

importlib.machinery.DEBUG_BYTECODE_SUFFIXES¶: En lista med strängar som representerar filsuffixen för icke-optimerade bytekodsmoduler.

Tillagd i version 3.3.

Föråldrad sedan version 3.5: Använd BYTECODE_SUFFIXES istället.

importlib.machinery.OPTIMIZED_BYTECODE_SUFFIXES¶: En lista med strängar som representerar filsuffixen för optimerade bytecode-moduler.

Tillagd i version 3.3.

Föråldrad sedan version 3.5: Använd BYTECODE_SUFFIXES istället.

importlib.machinery.BYTECODE_SUFFIXES¶: En lista med strängar som representerar de erkända filsuffixen för bytecode-moduler (inklusive den inledande punkten).

Tillagd i version 3.3.

Ändrad i version 3.5: Värdet är inte längre beroende av __debug__.

importlib.machinery.EXTENSION_SUFFIXES¶: En lista med strängar som representerar de identifierade filsuffixen för tilläggsmoduler.

Tillagd i version 3.3.

importlib.machinery.all_suffixes()¶: Returnerar en kombinerad lista med strängar som representerar alla filsuffix för moduler som känns igen av standardimportmaskineriet. Detta är ett hjälpmedel för kod som helt enkelt behöver veta om en filsystemssökväg potentiellt hänvisar till en modul utan att behöva några detaljer om typen av modul (till exempel inspect.getmodulename()).

Tillagd i version 3.3.

class importlib.machinery.BuiltinImporter¶

En importer för inbyggda moduler. Alla kända inbyggda moduler finns listade i sys.builtin_module_names. Den här klassen implementerar ABC:erna importlib.abc.MetaPathFinder och importlib.abc.InspectLoader.

Endast klassens metoder definieras av denna klass för att minska behovet av instansiering.

Ändrad i version 3.5: Som en del av PEP 489 implementerar den inbyggda importören nu Loader.create_module() och Loader.exec_module()

class importlib.machinery.FrozenImporter¶

En importer för frysta moduler. Denna klass implementerar ABC:erna importlib.abc.MetaPathFinder och importlib.abc.InspectLoader.

Endast klassens metoder definieras av denna klass för att minska behovet av instansiering.

Ändrad i version 3.4: Fått metoderna create_module() och exec_module().

class importlib.machinery.WindowsRegistryFinder¶

Finder för moduler som deklareras i Windows-registret. Den här klassen implementerar importlib.abc.MetaPathFinder ABC.

Endast klassens metoder definieras av denna klass för att minska behovet av instansiering.

Tillagd i version 3.3.

Föråldrad sedan version 3.6: Använd site-konfigurationen istället. Framtida versioner av Python kanske inte aktiverar den här sökaren som standard.

class importlib.machinery.PathFinder¶

En Finder för sys.path och paketets __path__ attribut. Den här klassen implementerar importlib.abc.MetaPathFinder ABC.

Endast klassens metoder definieras av denna klass för att minska behovet av instansiering.

classmethod find_spec(fullname, path=None, target=None)¶: Klassmetod som försöker hitta en spec för den modul som anges av fullname på sys.path eller, om definierad, på path. För varje sökvägspost som genomsöks kontrolleras sys.path_importer_cache. Om ett icke-falskt objekt hittas används det som path entry finder för att leta efter den modul som söks. Om ingen post hittas i sys.path_importer_cache, söks i sys.path_hooks efter en sökare för sökvägsposten och, om den hittas, lagras den i sys.path_importer_cache tillsammans med en fråga om modulen. Om ingen sökare någonsin hittas lagras None i cachen och returneras.

Tillagd i version 3.4.

Ändrad i version 3.5: Om den aktuella arbetskatalogen - representerad av en tom sträng - inte längre är giltig returneras None men inget värde cachas i sys.path_importer_cache.

classmethod invalidate_caches()¶: Anropar importlib.abc.PathEntryFinder.invalidate_caches() på alla sökare som lagras i sys.path_importer_cache som definierar metoden. Annars raderas poster i sys.path_importer_cache som är inställda på None.

Ändrad i version 3.7: Poster med None i sys.path_importer_cache tas bort.

Ändrad i version 3.4: Anropar objekt i sys.path_hooks med den aktuella arbetskatalogen för '' (d.v.s. den tomma strängen).

class importlib.machinery.FileFinder(path, *loader_details)¶

En konkret implementation av importlib.abc.PathEntryFinder som cachar resultat från filsystemet.

Argumentet path är den katalog som sökaren ska söka i.

Argumentet loader_details är ett variabelt antal tuples med två objekt som var och en innehåller en laddare och en sekvens av filsuffix som laddaren känner igen. Laddarna förväntas vara callables som accepterar två argument, modulens namn och sökvägen till den fil som hittas.

Sökaren cachelagrar kataloginnehållet efter behov och gör stat-anrop för varje modulsökning för att kontrollera att cacheminnet inte är föråldrat. Eftersom cache-stalkeness är beroende av granulariteten i operativsystemets statusinformation om filsystemet, finns det ett potentiellt tävlingsförhållande där man söker efter en modul, skapar en ny fil och sedan söker efter den modul som den nya filen representerar. Om operationerna sker tillräckligt snabbt för att rymmas inom granulariteten för stat-anrop, kommer modulsökningen att misslyckas. För att förhindra att detta händer, när du skapar en modul dynamiskt, se till att anropa importlib.invalidate_caches().

Tillagd i version 3.3.

path¶: Den väg som sökaren kommer att söka i.

find_spec(fullname, target=None)¶: Försök att hitta specifikationen för att hantera fullname inom path.

Tillagd i version 3.4.

invalidate_caches()¶: Rensa ut den interna cachen.

classmethod path_hook(*loader_details)¶

En klassmetod som returnerar en closure för användning på sys.path_hooks. En instans av FileFinder returneras av stängningen med hjälp av sökvägsargumentet som ges till stängningen direkt och loader_details indirekt.

Om argumentet till stängningen inte är en befintlig katalog kommer ImportError att tas upp.

class importlib.machinery.SourceFileLoader(fullname, path)¶

En konkret implementation av importlib.abc.SourceLoader genom att underklassa importlib.abc.FileLoader och tillhandahålla några konkreta implementationer av andra metoder.

Tillagd i version 3.3.

name¶: Namnet på den modul som den här laddaren ska hantera.

path¶: Sökvägen till källfilen.

is_package(fullname)¶: Returnerar True om path verkar vara för ett paket.

path_stats(path)¶: Konkret implementering av importlib.abc.SourceLoader.path_stats().

set_data(path, data)¶: Konkret implementation av importlib.abc.SourceLoader.set_data().

load_module(name=None)¶: Konkret implementation av importlib.abc.Loader.load_module() där det är valfritt att ange namnet på den modul som ska laddas.

Deprecated since version 3.6, will be removed in version 3.15: Använd importlib.abc.Loader.exec_module() istället.

class importlib.machinery.SourcelessFileLoader(fullname, path)¶

En konkret implementation av importlib.abc.FileLoader som kan importera bytecode-filer (dvs. inga källkodsfiler existerar).

Observera att direkt användning av bytecode-filer (och därmed inte källkodsfiler) hindrar dina moduler från att kunna användas av alla Python-implementationer eller nya versioner av Python som ändrar bytecode-formatet.

Tillagd i version 3.3.

name¶: Namnet på den modul som laddaren ska hantera.

path¶: Sökvägen till bytekodfilen.

is_package(fullname)¶: Avgör om modulen är ett paket baserat på path.

get_code(fullname)¶: Returnerar kodobjektet för name som skapats från path.

get_source(fullname)¶: Returnerar None eftersom bytecode-filer inte har någon källa när denna laddare används.

load_module(name=None)¶

Konkret implementation av importlib.abc.Loader.load_module() där det är valfritt att ange namnet på den modul som ska laddas.

Deprecated since version 3.6, will be removed in version 3.15: Använd importlib.abc.Loader.exec_module() istället.

class importlib.machinery.ExtensionFileLoader(fullname, path)¶

En konkret implementation av importlib.abc.ExecutionLoader för tilläggsmoduler.

Argumentet fullname anger namnet på den modul som laddaren ska stödja. Argumentet path är sökvägen till filen för tilläggsmodulen.

Observera att import av en tilläggsmodul som standard kommer att misslyckas i undertolkar om den inte implementerar flerfasig init (se PEP 489), även om den annars skulle importeras framgångsrikt.

Tillagd i version 3.3.

Ändrad i version 3.12: Flerfasig init krävs nu för användning i undertolkar.

name¶: Namnet på den modul som laddaren stöder.

path¶: Sökväg till tilläggsmodulen.

create_module(spec)¶: Skapar modulobjektet från den givna specifikationen i enlighet med PEP 489.

Tillagd i version 3.5.

exec_module(module)¶: Initialiserar det givna modulobjektet i enlighet med PEP 489.

Tillagd i version 3.5.

is_package(fullname)¶: Returnerar True om filsökvägen pekar på ett pakets __init__-modul baserat på EXTENSION_SUFFIXES.

get_code(fullname)¶: Returnerar None eftersom tilläggsmoduler saknar ett kodobjekt.

get_source(fullname)¶: Returnerar None eftersom tilläggsmoduler inte har någon källkod.

get_filename(fullname)¶: Returnerar path.

Tillagd i version 3.4.

class importlib.machinery.NamespaceLoader(name, path, path_finder)¶

En konkret implementation av importlib.abc.InspectLoader för namespace-paket. Detta är ett alias för en privat klass och görs endast offentlig för introspektion av __loader__-attributet på namespace-paket:

>>> from importlib.machinery import NamespaceLoader
>>> import my_namespace
>>> isinstance(my_namespace.__loader__, NamespaceLoader)
True
>>> import importlib.abc
>>> isinstance(my_namespace.__loader__, importlib.abc.Loader)
True

Tillagd i version 3.11.

class importlib.machinery.ModuleSpec(name, loader, *, origin=None, loader_state=None, is_package=None)¶

En specifikation för en moduls importsystemrelaterade tillstånd. Detta exponeras vanligtvis som modulens attribut __spec__. Många av dessa attribut är också tillgängliga direkt på en modul: till exempel, module.__spec__.origin == module.__file__. Observera dock att även om värdena vanligtvis är likvärdiga kan de skilja sig åt eftersom det inte finns någon synkronisering mellan de två objekten. Det är t.ex. möjligt att uppdatera modulens __file__ vid körning, men detta återspeglas inte automatiskt i modulens __spec__.origin, och vice versa.

Tillagd i version 3.4.

name¶: Modulens fullständigt kvalificerade namn (se module.__name__). Termen finder bör alltid sätta detta attribut till en icke-tom sträng.

loader¶: Den loader som används för att ladda modulen (se module.__loader__). Attributet bör alltid anges av finder.

origin¶: Den plats som loader ska använda för att ladda modulen (se module.__file__). För moduler som läsas in från en .py-fil är detta till exempel filnamnet. finder ska alltid ange detta attribut till ett meningsfullt värde som loader kan använda. I det ovanliga fallet att det inte finns något (som för namnrymdspaket) ska det ställas in på None.

submodule_search_locations¶

En (eventuellt tom) sekvens av strängar som räknar upp de platser där ett pakets undermoduler kommer att hittas (se module.__path__). För det mesta kommer det bara att finnas en enda katalog i den här listan.

finder bör sätta detta attribut till en sekvens, även en tom sådan, för att ange för importsystemet att modulen är ett paket. Det bör sättas till None för icke-paketmoduler. Det sätts automatiskt senare till ett speciellt objekt för namnrymdspaket.

loader_state¶: finder kan sätta detta attribut till ett objekt som innehåller ytterligare modulspecifika data att använda vid laddning av modulen. Annars bör det sättas till None.

cached¶: Filnamnet för en kompilerad version av modulens kod (se module.__cached__). Attributet bör alltid anges av finder men kan vara None för moduler som inte behöver lagra kompilerad kod.

parent¶: (Skrivskyddad) Det fullständigt kvalificerade namnet på det paket som modulen finns i (eller den tomma strängen för en modul på högsta nivån). Se module.__package__. Om modulen är ett paket är detta samma sak som name.

has_location¶: True om specifikationens origin` hänvisar till en laddningsbar plats, False annars. Detta värde påverkar hur origin tolkas och hur modulens __file__ fylls i.

class importlib.machinery.AppleFrameworkLoader(name, path)¶

En specialisering av importlib.machinery.ExtensionFileLoader som kan ladda tilläggsmoduler i Framework-format.

För kompatibilitet med iOS App Store måste alla binära moduler i en iOS-app vara dynamiska bibliotek som ingår i ett ramverk med lämpliga metadata som lagras i mappen Frameworks i den paketerade appen. Det får bara finnas ett enda binärt program per ramverk och det får inte finnas något körbart binärt material utanför Frameworks-mappen.

För att uppfylla detta krav paketeras inte binärfiler för tilläggsmoduler som .so-filer i sys.path när de körs på iOS, utan som enskilda fristående ramverk. För att hitta dessa ramverk registreras laddaren mot filändelsen .fwork, där en .fwork-fil fungerar som platshållare i den ursprungliga platsen för binärfilen i sys.path. Filen .fwork innehåller sökvägen till den faktiska binärfilen i mappen Frameworks, relativt app-paketet. För att möjliggöra återföring av en ramverkspaketerad binärfil till den ursprungliga platsen förväntas ramverket innehålla en fil med namnet .origin som innehåller sökvägen till filen .fwork, relativt app-paketet.

Tänk till exempel på fallet med en import from foo.bar import _whiz, där _whiz implementeras med den binära modulen sources/foo/bar/_whiz.abi3.so, där sources är den plats som registrerats på sys.path, relativt programpaketet. Den här modulen måste distribueras som Frameworks/foo.bar._whiz.framework/foo.bar._whiz (ramverkets namn skapas från modulens fullständiga importsökväg), med en Info.plist-fil i katalogen .framework som identifierar binärfilen som ett ramverk. Modulen foo.bar._whiz skulle representeras på den ursprungliga platsen med en källor/foo/bar/_whiz.abi3.fwork markörfil, som innehåller sökvägen Frameworks/foo.bar._whiz/foo.bar._whiz. Ramverket skulle också innehålla Frameworks/foo.bar._whiz.framework/foo.bar._whiz.origin, som innehåller sökvägen till filen .fwork.

När en modul laddas med den här laddaren kommer __file__ för modulen att rapporteras som platsen för filen .fwork. Detta gör att kod kan använda __file__ för en modul som ett ankare för filsystemtraversering. Spec-ursprunget kommer dock att referera till platsen för den verkliga binära filen i mappen .framework.

Xcode-projektet som bygger appen ansvarar för att konvertera alla .so-filer från var de än finns i PYTHONPATH till ramverk i mappen Frameworks (inklusive att ta bort tillägg från modulfilen, lägga till metadata för ramverket och signera det resulterande ramverket) och skapa filerna .fwork och .origin. Detta görs vanligtvis med ett byggsteg i Xcode-projektet; se iOS-dokumentationen för detaljer om hur man konstruerar detta byggsteg.

Tillagd i version 3.13.

Tillgänglighet: iOS.

name¶: Namnet på den modul som laddaren stöder.

path¶: Sökväg till filen .fwork för tilläggsmodulen.

`importlib.util` – Verktygskod för importörer¶

Källkod: Lib/importlib/util.py

Denna modul innehåller de olika objekt som hjälper till vid konstruktionen av en importer.

importlib.util.MAGIC_NUMBER¶: Byte som representerar bytekodens versionsnummer. Om du behöver hjälp med att ladda/skriva bytecode kan du överväga importlib.abc.SourceLoader.

Tillagd i version 3.4.

importlib.util.cache_from_source(path, debug_override=None, *, optimization=None)¶

Returnerar PEP 3147/PEP 488 sökvägen till den bytekompilerade filen som är associerad med källan path. Till exempel, om väg är /foo/bar/baz.py skulle returvärdet vara /foo/bar/__pycache__/baz.cpython-32.pyc för Python 3.2. Strängen cpython-32 kommer från den aktuella magiska taggen (se get_tag(); om sys.implementation.cache_tag inte är definierad kommer NotImplementedError` att anges).

Parametern optimization används för att ange optimeringsnivån för bytecode-filen. En tom sträng representerar ingen optimering, så /foo/bar/baz.py med en optimering på '' kommer att resultera i en bytekodssökväg på /foo/bar/__pycache__/baz.cpython-32.pyc. None gör att tolkens optimeringsnivå används. Alla andra värdens strängrepresentation används, så /foo/bar/baz.py med en optimering på 2 kommer att leda till bytekodssökvägen /foo/bar/__pycache__/baz.cpython-32.opt-2.pyc. Strängrepresentationen av optimering kan endast vara alfanumerisk, annars uppstår ValueError.

Parametern debug_override är föråldrad och kan användas för att åsidosätta systemets värde för __debug__. Värdet True motsvarar inställningen av optimization till den tomma strängen. Ett värde på False är detsamma som att sätta optimization till 1. Om både debug_override och optimization inte är None så genereras TypeError.

Tillagd i version 3.4.

Ändrad i version 3.5: Parametern optimization har lagts till och parametern debug_override har tagits bort.

Ändrad i version 3.6: Accepterar en path-like object.

importlib.util.source_from_cache(path)¶: Givet sökvägen till ett PEP 3147-filnamn, returnera den associerade källkodsfilsökvägen. Till exempel, om sökväg är /foo/bar/__pycache__/baz.cpython-32.pyc skulle den returnerade sökvägen vara /foo/bar/baz.py. path behöver inte existera, men om den inte överensstämmer med PEP 3147 eller PEP 488 format, kommer ett ValueError att uppstå. Om sys.implementation.cache_tag inte är definierad, genereras NotImplementedError.

Tillagd i version 3.4.

Ändrad i version 3.6: Accepterar en path-like object.

importlib.util.decode_source(source_bytes)¶: Avkodar de angivna byte som representerar källkod och returnerar den som en sträng med universella nya linjer (enligt importlib.abc.InspectLoader.get_source()).

Tillagd i version 3.4.

importlib.util.resolve_name(name, package)¶

Omvandlar ett relativt modulnamn till ett absolut.

Om name inte har några inledande punkter returneras helt enkelt name. Detta gör det möjligt att använda importlib.util.resolve_name('sys', __spec__.parent) utan att kontrollera om argumentet package behövs.

ImportError tas upp om name är ett relativt modulnamn men package är ett falskt värde (t.ex. None eller den tomma strängen). ImportError tas också upp om ett relativt namn skulle undkomma det innehållande paketet (t.ex. begära ..bacon inom paketet spam).

Tillagd i version 3.3.

Ändrad i version 3.9: För att förbättra konsistensen med importdeklarationer, skicka ImportError istället för ValueError för ogiltiga relativa importförsök.

importlib.util.find_spec(name, package=None)¶

Hitta spec för en modul, eventuellt i förhållande till det angivna package-namnet. Om modulen finns i sys.modules, returneras sys.modules[name].__spec__ (såvida inte specifikationen skulle vara None eller inte är inställd, i vilket fall ValueError` tas upp). Annars görs en sökning med hjälp av sys.meta_path. None returneras om ingen specifikation hittas.

Om namn är för en undermodul (innehåller en punkt) importeras den överordnade modulen automatiskt.

name och package fungerar på samma sätt som för import_module().

Tillagd i version 3.4.

Ändrad i version 3.7: Utlöser ModuleNotFoundError istället för AttributeError om package i själva verket inte är ett paket (dvs. saknar attributet __path__).

importlib.util.module_from_spec(spec)¶

Skapa en ny modul baserad på spec och spec.loader.create_module.

Om spec.loader.create_module inte returnerar None, kommer inga befintliga attribut att återställas. Inte heller kommer något AttributeError att uppstå om det utlöses under åtkomst till spec eller inställning av ett attribut på modulen.

Denna funktion är att föredra framför att använda types.ModuleType för att skapa en ny modul eftersom spec används för att ange så många importkontrollerade attribut för modulen som möjligt.

Tillagd i version 3.5.

importlib.util.spec_from_loader(name, loader, *, origin=None, is_package=None)¶: En fabriksfunktion för att skapa en ModuleSpec-instans baserad på en laddare. Parametrarna har samma betydelse som de har för ModuleSpec. Funktionen använder tillgängliga loader API:er, såsom InspectLoader.is_package(), för att fylla i eventuell saknad information om specifikationen.

Tillagd i version 3.4.

importlib.util.spec_from_file_location(name, location, *, loader=None, submodule_search_locations=None)¶: En fabriksfunktion för att skapa en ModuleSpec-instans baserat på sökvägen till en fil. Saknad information kommer att fyllas i i specifikationen genom att använda API:er för laddare och genom att antyda att modulen kommer att vara filbaserad.

Tillagd i version 3.4.

Ändrad i version 3.6: Accepterar en path-like object.

importlib.util.source_hash(source_bytes)¶: Returnerar hashen av source_bytes som bytes. En hashbaserad .pyc-fil bäddar in source_hash() av motsvarande källfils innehåll i sitt huvud.

Tillagd i version 3.7.

importlib.util._incompatible_extension_module_restrictions(*, disable_check)¶

En kontexthanterare som tillfälligt kan hoppa över kompatibilitetskontrollen för tilläggsmoduler. Som standard är kontrollen aktiverad och kommer att misslyckas när en enfasig init-modul importeras i en undertolk. Den kommer också att misslyckas för en flerfasig init-modul som inte uttryckligen stöder en GIL per tolk, när den importeras i en tolk med sin egen GIL.

Observera att den här funktionen är avsedd för ett ovanligt fall, ett fall som sannolikt kommer att försvinna så småningom. Det finns en ganska stor chans att det här inte är vad du letade efter.

Du kan få samma effekt som den här funktionen genom att implementera det grundläggande gränssnittet för flerfasig init (PEP 489) och ljuga om stöd för flera tolkar (eller GIL per tolk).

Varning

Om du använder den här funktionen för att inaktivera kontrollen kan det leda till oväntat beteende och till och med krascher. Den bör endast användas under utveckling av tilläggsmoduler.

Tillagd i version 3.12.

class importlib.util.LazyLoader(loader)¶

En klass som skjuter upp exekveringen av laddaren för en modul tills dess att modulen har ett attribut åtkomligt.

Denna klass fungerar endast med laddare som definierar exec_module() eftersom kontroll över vilken modultyp som används för modulen krävs. Av samma skäl måste laddarens metod create_module() returnera None eller en typ för vilken attributet __class__ kan ändras, och inte heller använda slots. Slutligen kommer moduler som ersätter objektet som placerats i sys.modules inte att fungera eftersom det inte finns något sätt att på ett säkert sätt ersätta modulreferenserna i hela tolken; ValueError tas upp om en sådan ersättning upptäcks.

Anteckning

För projekt där uppstartstiden är kritisk gör den här klassen det möjligt att potentiellt minimera kostnaden för att ladda en modul om den aldrig används. För projekt där starttiden inte är avgörande är det starkt avrått från att använda denna klass eftersom felmeddelanden som skapas under laddningen skjuts upp och därmed uppträder utanför sitt sammanhang.

Tillagd i version 3.5.

Ändrad i version 3.6: Började anropa create_module(), vilket tog bort kompatibilitetsvarningen för importlib.machinery.BuiltinImporter och importlib.machinery.ExtensionFileLoader.

classmethod factory(loader)¶

En klassmetod som returnerar en callable som skapar en lazy loader. Detta är tänkt att användas i situationer där laddaren skickas av klassen istället för av instansen:

suffix = importlib.machinery.SOURCE_SUFFIXES
loader = importlib.machinery.SourceFileLoader
lazy_loader = importlib.util.LazyLoader.factory(loader)
finder = importlib.machinery.FileFinder(sökväg, (lazy_loader, suffixes))

Exempel¶

Importera programmatiskt¶

För att programmatiskt importera en modul, använd importlib.import_module().

import importlib

itertools = importlib.import_module('itertools')

Kontroll av om en modul kan importeras¶

Om du behöver ta reda på om en modul kan importeras utan att faktiskt göra importen, bör du använda importlib.util.find_spec().

Observera att om name är en undermodul (innehåller en punkt) kommer importlib.util.find_spec() att importera föräldramodulen.

import importlib.util
import sys

# For illustrative purposes.
name = 'itertools'

if name in sys.modules:
    print(f"{name!r} already in sys.modules")
elif (spec := importlib.util.find_spec(name)) is not None:
    # If you chose to perform the actual import ...
    module = importlib.util.module_from_spec(spec)
    sys.modules[name] = module
    spec.loader.exec_module(module)
    print(f"{name!r} has been imported")
else:
    print(f"can't find the {name!r} module")

Importera en källfil direkt¶

Det här receptet bör användas med försiktighet: det är en approximation av en importsats där filsökvägen anges direkt, i stället för att sys.path söks. Alternativ bör först övervägas, till exempel att ändra sys.path när en riktig modul krävs, eller att använda runpy.run_path() när det globala namnrymden som uppstår när en Python-fil körs är lämplig.

Om du vill importera en Python-källfil direkt från en sökväg använder du följande recept:

import importlib.util
import sys


def import_from_path(module_name, file_path):
    spec = importlib.util.spec_from_file_location(module_name, file_path)
    module = importlib.util.module_from_spec(spec)
    sys.modules[module_name] = module
    spec.loader.exec_module(module)
    return module


# For illustrative purposes only (use of `json` is arbitrary).
import json
file_path = json.__file__
module_name = json.__name__

# Similar outcome as `import json`.
json = import_from_path(module_name, file_path)

Implementering av lat import¶

Exemplet nedan visar hur man implementerar lazy imports:

>>> import importlib.util
>>> import sys
>>> def lazy_import(name):
...     spec = importlib.util.find_spec(name)
...     loader = importlib.util.LazyLoader(spec.loader)
...     spec.loader = loader
...     module = importlib.util.module_from_spec(spec)
...     sys.modules[name] = module
...     loader.exec_module(module)
...     return module
...
>>> lazy_typing = lazy_import("typing")
>>> #lazy_typing is a real module object,
>>> #but it is not loaded in memory yet.
>>> lazy_typing.TYPE_CHECKING
False

Konfigurera en importer¶

För djupa anpassningar av import vill du vanligtvis implementera en importer. Detta innebär att hantera både finder och loader sidan av saker och ting. För sökare finns det två varianter att välja mellan beroende på dina behov: en meta path finder eller en path entry finder. Den förra är vad du skulle sätta på sys.meta_path medan den senare är vad du skapar med hjälp av en path entry hook på sys.path_hooks som fungerar med sys.path-poster för att potentiellt skapa en sökare. Det här exemplet visar hur du registrerar dina egna importörer så att import använder dem (för att skapa en egen importör, läs dokumentationen för lämpliga klasser som definieras i det här paketet):

import importlib.machinery
import sys

# For illustrative purposes only.
SpamMetaPathFinder = importlib.machinery.PathFinder
SpamPathEntryFinder = importlib.machinery.FileFinder
loader_details = (importlib.machinery.SourceFileLoader,
                  importlib.machinery.SOURCE_SUFFIXES)

# Setting up a meta path finder.
# Make sure to put the finder in the proper location in the list in terms of
# priority.
sys.meta_path.append(SpamMetaPathFinder)

# Setting up a path entry finder.
# Make sure to put the path hook in the proper location in the list in terms
# of priority.
sys.path_hooks.append(SpamPathEntryFinder.path_hook(loader_details))

Närmar sig `importlib.import_module()`¶

Import i sig är implementerat i Python-kod, vilket gör det möjligt att exponera det mesta av importmaskineriet genom importlib. Följande hjälper till att illustrera de olika API:erna som importlib exponerar genom att tillhandahålla en ungefärlig implementering av importlib.import_module():

import importlib.util
import sys

def import_module(name, package=None):
    """An approximate implementation of import."""
    absolute_name = importlib.util.resolve_name(name, package)
    try:
        return sys.modules[absolute_name]
    except KeyError:
        pass

    path = None
    if '.' in absolute_name:
        parent_name, _, child_name = absolute_name.rpartition('.')
        parent_module = import_module(parent_name)
        path = parent_module.__spec__.submodule_search_locations
    for finder in sys.meta_path:
        spec = finder.find_spec(absolute_name, path)
        if spec is not None:
            break
    else:
        msg = f'No module named {absolute_name!r}'
        raise ModuleNotFoundError(msg, name=absolute_name)
    module = importlib.util.module_from_spec(spec)
    sys.modules[absolute_name] = module
    spec.loader.exec_module(module)
    if path is not None:
        setattr(parent_module, child_name, module)
    return module

`importlib` — Implementeringen av `import`¶

Introduktion¶

Funktioner¶

`importlib.abc` – Abstrakta basklasser relaterade till import¶

`importlib.machinery` – Importörer och sökvägs-hooks¶

`importlib.util` – Verktygskod för importörer¶

Exempel¶

Importera programmatiskt¶

Kontroll av om en modul kan importeras¶

Importera en källfil direkt¶

Implementering av lat import¶

Konfigurera en importer¶

Närmar sig `importlib.import_module()`¶

Innehåll

Föregående ämne

Nästa ämne

Denna sidan

importlib — Implementeringen av import¶

Introduktion¶

Funktioner¶

importlib.abc – Abstrakta basklasser relaterade till import¶

importlib.machinery – Importörer och sökvägs-hooks¶

importlib.util – Verktygskod för importörer¶

Exempel¶

Importera programmatiskt¶

Kontroll av om en modul kan importeras¶

Importera en källfil direkt¶

Implementering av lat import¶

Konfigurera en importer¶

Närmar sig importlib.import_module()¶

`importlib` — Implementeringen av `import`¶

`importlib.abc` – Abstrakta basklasser relaterade till import¶

`importlib.machinery` – Importörer och sökvägs-hooks¶

`importlib.util` – Verktygskod för importörer¶

Närmar sig `importlib.import_module()`¶