Zanurkuj w Pythonie/Standardowy strumień wejścia, wyjścia i błędów: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
Piotr (dyskusja | edycje)
Piotr (dyskusja | edycje)
koniec
Linia 1:
{{WEdycji}}
 
{{Podświetl|py}}
== Standardowy strumień wejścia, wyjścia i błędów==
Linia 94 ⟶ 92:
entering function
 
# Ta skrótowa składnia wyrażenia <tt>print</tt> może być wykoryzstywanewykorzystywana do pisania do dowolnego, otwartego pliku, lub do ''obiektu pliko-podobnego''. W tym przypadku, możemy przekierować pojedynczą instrukcję <tt>print</tt> do <tt>stderr</tt> bez wpływu na następne instrukcje <tt>print</tt>.
 
Z innej strony, standardowe wejścia jest obiektem pliku tylko do odczytu i reprezentuje dane przechodzące z niektórych wcześniejszych programów. Prawdopodobnie nie jest to zrozumiałe dla klasycznych użytkowników Mac OS-a lub nawet dla użytkowników Windows, którzy nie mieli za wiele do czynienia z linią poleceń MS-DOS-a. Działa to w ten sposób, że konstruujemy ciąg poleceń w jednej linii, w taki sposób, że to co jeden program wypisuje na wyjście, następny w tym ciągu traktuje jako wejście. Pierwszy program prosto wypisuje wszystko na standardowe wyjście (bez korzystania ze specjalnych przekierowań, wykorzystuje normalną instrukcję <tt>print</tt> itp.), a następny program czyta ze standardowego wejścia, a system operacyjny udostępnia połączenie pomiędzy wyjściem pierwszego programu, a wyjściem kolejnego.
Standard input, on the other hand, is a read-only file object, and it represents the data flowing into the program from some previous program. This will likely not make much sense to classic Mac OS users, or even Windows users unless you were ever fluent on the MS-DOS command line. The way it works is that you can construct a chain of commands in a single line, so that one program's output becomes the input for the next program in the chain. The first program simply outputs to standard output (without doing any special redirecting itself, just doing normal print statements or whatever), and the next program reads from standard input, and the operating system takes care of connecting one program's output to the next program's input.
 
'''ExamplePrzykład 10.12. ChainingCiąg commandspoleceń'''
<nowiki>
[you@localhost kgp]$ python kgp.py -g binary.xml #(1)
Linia 119 ⟶ 117:
</nowiki>
 
# Jak zobaczyliśmy w podrozdziale 9.1, “Nurkujemy”, polecenie to wyświetli ciąg ośmiu przypadkowych bitów, <tt>0</tt> lub <tt>1</tt>.
# As you saw in Section 9.1, “Diving in”, this will print a string of eight random bits, 0 or 1.
# Dzięki temu po prostu wypiszemy całą zawartość pliku <tt>binary.xml</tt>. (Użytkownicy Windowsa powinni wykorzystać polecenie <tt>type</tt> zamiast <tt>cat</tt>.)
# This simply prints out the entire contents of binary.xml. (Windows users should use type instead of cat.)
# Polecenie to wypisuje zawartość pliku <tt>binary.xml</tt>, ale znak "|" (ang. ''pipe''), oznacza, że standardowe wyjście nie zostanie wypisana na ekran. Zamiast tego, zawartość standardowego wyjścia zostanie wykorzystane jako standardowe wejście następnego programu, który w tym przypadku jest skryptem Pythona.
# This prints the contents of binary.xml, but the “|” character, called the “pipe” character, means that the contents will not be printed to the screen. Instead, they will become the standard input of the next command, which in this case calls your Python script.
# Zamiast określać modułu (np. <tt>binary.xml</tt>), dajemy "-", który każe naszemy skryptowi wczytać gramatykę ze standardowego wejścia, zamiast z określonego pliku na dysku. (Więcej o tym, w jaki sposób to się dzieje w następnym przykładzie.) Zatem efekt będzie taki sam, jak w pierwszym poleceniu, gdzie bezpośrednio określamy plik gramatyki, ale tutaj zwróćmy uwagę na rozszerzone możliwości. Zamiast wywoływać <tt>cat binary.xml</tt>, moglibyśmy uruchomić skrypt, który by dynamicznie generował gramatykę, a następnie mógłby ją doprowadzić do naszego skryptu. Dane mogłyby przyjść skądkolwiek: z bazy danych, innego skryptu generującego gramatykę lub jeszcze inaczej. Zaletą tego jest to, że nie musimy zmieniać w żaden sposób <tt>kgp.py</tt>, aby dołączyć jakąś funkcjonalność. Jedynie, co potrzebujemy, to możliwość wczytania gramatyki ze standardowego wejścia, a całą logikę dodatkowej funkcjonalności możemy rozdzielić wewnątrz innego programu.
# Instead of specifying a module (like binary.xml), you specify “-”, which causes your script to load the grammar from standard input instead of from a specific file on disk. (More on how this happens in the next example.) So the effect is the same as the first syntax, where you specified the grammar filename directly, but think of the expansion possibilities here. Instead of simply doing cat binary.xml, you could run a script that dynamically generates the grammar, then you can pipe it into your script. It could come from anywhere: a database, or some grammar-generating meta-script, or whatever. The point is that you don't need to change your kgp.py script at all to incorporate any of this functionality. All you need to do is be able to take grammar files from standard input, and you can separate all the other logic into another program.
 
Więc w jaki sposób skrypt "wie", żeby czytać ze standardowego wejścia, gdy plik gramatyki to "-"? To nie jest żadna magia; to tylko właśnie prosty kod.
So how does the script “know” to read from standard input when the grammar file is “-”? It's not magic; it's just code.
 
'''ExamplePrzykład 10.13. ReadingCzytanie fromze standardstandardowego inputwejścia inw <tt>kgp.py</tt>'''
 
 
Linia 140 ⟶ 138:
[... ciach ...]
 
# ThisJest isto thefunkcja <tt>openAnything</tt> function fromz <tt>toolbox.py</tt>, whichktórą youwcześniej previouslybadaliśmy examinedw in Sectionpodrozdziale 10.1, “Abstracting"Abstrakcyjne inputźródła sources”wejścia”. AllWszystko, you'veco donemusimy iszrobić, addto threedodanie linestrzech oflinii codekodu atna thepoczątku, beginningaby of the function to checksprawdzić, ifczym theźródłem sourcenie isjest "-"; ifjeśli sotak, youto returnzwracamy <tt>sys.stdin</tt>. ReallyNaprawdę, that'sto tylko ittyle! RememberPamiętasz, <tt>stdin</tt> isjest a''obiektem filepliko-likepodobnym'' objectz with ametodą read method, so the restwięc ofpozostałą theczęść codekodu (inw <tt>kgp.py</tt>, wheregdzie youwywołujemy callfunkcję <tt>openAnything</tt>) doesn'tw żaden changesposób anie bitzmieniamy.
 
<noinclude>