Zanurkuj w Pythonie/Pakiety: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
Piotr (dyskusja | edycje)
mNie podano opisu zmian
Piotr (dyskusja | edycje)
przetłumaczone
Linia 1:
{{WEdycji}}
 
{{Podświetl|py}}
== Pakiety ==
Linia 6 ⟶ 4:
W rzeczywistość przetwarzanie dokumentu XML jest bardzo proste, wystarczy jedna linia kodu. Jednakże, zanim dojdziemy do tej linii kodu, będziemy musieli krótko omówić, czym są pakiety.
 
'''Przykład 9.5. Ładowanie dokumentu XML (a sneak peek)'''
 
>>> from xml.dom import minidom #(1)
Linia 17 ⟶ 15:
'''Przykład 9.6. Plikowa struktura pakietu'''
 
<span>Python21/ rootkatalog Pythongłówny installationinstalacji Pythona (homekatalog ofdomowy theplików executablewykonywalnych)
|
+−−lib/ librarykatalog directorybibliotek (homekatalog ofdomowy thestandardowych standard library modulesmodułów)
|
+−− xml/ xml packagepakiet (reallyw justrzeczywistości akatalog directoryz withinnymi otherrzeczami stuffwewnątrz in itniego)
|
+−−sax/ xml.sax packagepakiet (againponownie, justwłaściwie a directorykatalog)
|
+−−dom/ xml.dom packagepakiet (containszawiera <tt>minidom.py</tt>)
|
+−−parsers/ xml.parsers packagepakiet (usedużywany internallywewnętrznie)</span>
 
Dlatego kiedy powiesz <tt>from xml.dom import minidom</tt>, Python zrozumie to jako "znajdź w katalogu <tt>xml</tt> katalog <tt>dom</tt>, a następnie szukaj tutaj modułu <tt>minidom</tt> i zaimportuj go jako <tt>minidom</tt>". Lecz Python jest także mądrzejszy; nie tylko możesz zaimportować cały moduł zawarty wewnątrz pakietu, ale także możesz wybiórczo zaimportować wybrane klasy czy funkcje z modułu znajdującego się wewnątrz pakietu. Możesz także zaimportować sam pakiet jako moduł. Składnia będzie taka sama; Python wywnioskuje, co masz na myśli na podstawie struktury plików pakietu i automatycznie wykona poprawną czynność.
Linia 55 ⟶ 53:
# Tutaj importujemy jako główny poziom pakietu <tt>xml</tt>.
 
Więc jak może pakiet (który na dysku jest katalogiem) zostać zaimportowany i traktowany jako moduł (a który jest zawsze plikiem na dysku)? Odpowiedzią jest magiczny plik <tt>__init__.py</tt>. Widzimy, że pakiety nie są po prostu katalogami. Są one katalogami ze specyficznym plikiem wewnątrz, <tt>__init__.py</tt>. Plik ten definiuje atrybuty i metody tego pakietu. Na przykład, <tt>xml.dom</tt> posiada klasę <tt>Node</tt>, która jest zdefiowana w <tt>xml/dom/__init__.py</tt>. Kiedy importujesz pakiet jako moduł (np. <tt>dom</tt> z <tt>xml</tt>-a), to tak naprawdę importujesz jego plik <tt>__init__.py</tt>.
So how can a package (which is just a directory on disk) be imported and treated as a module (which is always a file
on disk)? The answer is the magical __init__.py file. You see, packages are not simply directories; they are
directories with a specific file, __init__.py, inside. This file defines the attributes and methods of the package.
For instance, xml.dom contains a Node class, which is defined in xml/dom/__init__.py. When you import a
package as a module (like dom from xml), you're really importing its __init__.py file.
 
{{Infobox|
A package is a directory with the special __init__.py file in it. The __init__.py file defines the attributes
Pakiet jest katalogiem ze specjalnym plikiem <tt>__init__.py</tt> wewnątrz niego. Plik <tt>__init__.py</tt> definiuje atrybuty i metody pakietu. Nie musi on definiować niczego, może być nawet pustym plikiem, lecz musi istnieć. Jeśli nie istnieje plik <tt>__init__.py</tt>, katalog jest tylko katalogiem, a nie pakietem, więc nie może być zaimportowany lub zawierać moduły, czy też zagnieżdżone pakiety.
and methods of the package. It doesn't need to define anything; it can just be an empty file, but it has to exist. But if
}}
__init__.py doesn't exist, the directory is just a directory, not a package, and it can't be imported or contain
modules or nested packages.
So why bother with packages? Well, they provide a way to logically group related modules. Instead of having an xml
package with sax and dom packages inside, the authors could have chosen to put all the sax functionality in
xmlsax.py and all the dom functionality in xmldom.py, or even put all of it in a single module. But that would
have been unwieldy (as of this writing, the XML package has over 3000 lines of code) and difficult to manage
(separate source files mean multiple people can work on different areas simultaneously).
 
Więc dlaczego męczyć się z pakietami? Umożliwiają one logiczne pogrupowanie powiązanych ze sobą modułami. Zamiast stworzenia pakietu <tt>xml</tt> z wewnętrznymi pakietami <tt>sax</tt> i <tt>dom</tt>, autorzy mogliby umieścić całą funkcjonalność <tt>sax</tt> w <tt>xmlsax.py</tt>, a całą funkcjonalność <tt>dom</tt> w <tt>xmldom.py</tt>, czy też nawet zamieścić wszystko w pojedyńczym module. Jednak byłoby to niewygodne (podczas pisania tego podręcznika pakiet <tt>XML</tt> posiadał prawie 6000 linii kodu) i trudne w zarządzaniu
If you ever find yourself writing a large subsystem in Python (or, more likely, when you realize that your small
(dzięki oddzielnym plikom źródłowym, wiele osób może równocześnie pracować nad różnymi częściami).
subsystem has grown into a large one), invest some time designing a good package architecture. It's one of the many
things Python is good at, so take advantage of it.
 
Jeśli kiedykolwiek będzie planował napisać wielki podsysten w Pythonie (lub bardziej prawdopodobnie, kiedy zauważysz, że twój mały podsystem rozrósł się do dużego), zainwestuj trochę czasu na zaprojektowanie dobrej architektury systemu pakietów. Jest to jedna z wielu rzeczy w Pythonie, w którym jest dobry, więc skorzystajmy z tej zalety.
 
<noinclude>