Liste von Definitionen u.ä.

Kapitel 14: Python-Installation, Shell,
Werkzeuge
Grundlagen der Programmierung 1
Holger Karl
Wintersemester 2016/2017
Inhaltsverzeichnis
Inhaltsverzeichnis
1
Abbildungsverzeichnis
2
Liste von Definitionen u.ä.
14.1
Überblick . . . . . . . .
14.2
Python: Installation . .
14.3
Editoren, IDEs . . . . .
14.4
Debugging und Testing
14.5
Testen . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3
3
6
7
11
14.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 12
Abbildungsverzeichnis
14.1
14.2
14.3
14.4
14.5
Start eines Terminalfensters in Jupyterhub
Emacs thumbs . . . . . . . . . . . . . . . .
Aufwand der Fehlerbeseitigung . . . . . .
Wissen der Alten . . . . . . . . . . . . . .
Good debuggers help . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
. 6
.
7
. 9
. 11
Liste von Definitionen u.ä.
2
14.1. Überblick
14.1
14.1.1
Überblick
Was bisher geschah
• Wir haben Python-Programme bisher in zwei Kontexten entwickelt bzw.
ausgeführt :
– Im einem Jupyter-Notebook
– Im Pythontutor
• Didaktisch (hoffentlich) wertvoll, aber für Produktiveinsatz nur bedingt
geeignet
– Jupyter-Notebooks: durchaus auch produktiv!
14.1.2
Dieses Kapitel
• Installation von Python
• Installation von Modulen
• Werkzeuge:
– Editoren, Entwicklungsumgebungen
– Debugger
• Debugging und Test-Techniken
14.2
14.2.1
Python: Installation
Installation
• Webseite für Download
• Ordentliches Betriebssystem: In der Regel vorhanden
– Falls bestimmte Version fehlt: Bordmittel (apt-get install
... u.ä.)
• Windows: Viel Glück!
14.2.2
Python im Terminal
• Der Python-Interpreter kann direkt als Programm aufgerufen werden
• Führt dann REPL aus
– Read: Von Eingabe, Tastatur
– Print: Auf Ausgabe, Bildschirm
• In Jupyterhub ganz einfach: New Terminal
3
4
Liste von Definitionen u.ä.
Abbildung 14.1: Start eines Terminalfensters in Jupyterhub
Abbildung 14.1 zeigt, wie Sie aus der Jupyterhub-Webseite einfach ein Terminal starten können. Die Übungen werden mehr Details zur Nutzung von
Terminals, shells, etc. enthalten.
14.2.3
Packages installieren
Standardwerkzeuge für weitere Packages pip
•
•
•
•
•
14.2.4
Website
Übersicht lokal installierter Packages: pip list
Details zu Package: pip show MODULNAME
Suche nach Package: pip search MODU
Referenz: Python Package Index, mit 87310 Packages (August 2016)
Gekapselte Installation
• Standardinstallation: Neue Packages werden an vordefiniertem Ort gespeichert
– Erfordert in der Regel Adminstrator-Rechte
– Könnte andere Packages überschreiben
– Verhindert, unterschiedliche Versionen auszuprobieren
– Möglicherweise vertragen sich nicht alle Packages mit einander
– Packages können unterschiedliche Anforderungen stellen
• Daher: Für Packages gekapselte Installationsorte bereitstellen
– Virtual environments
• Werkzeug: Virtualenv
14.2. Python: Installation
14.2.5
Virtualenv
• Erzeugt und verwaltet virtuelle Python-Installationen
– Jede bekommt abgekapselten Installationsort
– Eigenen Satz der installierten Packages
– Ohne Adminstrator-Rechte möglich!
• Nutzung: einfacher mit virtualenvwrapper
14.2.6
Virtualenvwrapper
•
•
•
•
•
•
14.2.7
$> pip install virtualenvwrapper
$> mkvirtualenv jupyter
$> workon jupyter
(jupyter) $> pip install jupyter
...
(jupyter) $> deactivate
Nützliche Non-Standard-Module
• bpython: Stark verbesserte interaktive Nutzung des Interpreters
– Z.B. mit Vorschlägen verfügbarer Methoden bei Objekt, samt docstring
• requests: Package, um mit HTTP einfach umzugehen
1
2
3
import requests
r = requests.get("http://www.google.de")
print(r.json)
• Und viele mehr: Liste 1, Liste 2, Liste 3
14.2.8
Matplotlib
• Matplotlib: Alle Arten von Plots
1
2
3
%matplotlib notebook
import matplotlib.pyplot as plt
import math
4
5
6
x = [xx/50 for xx in range(0, 600)]
y = list(map(math.sin, x))
7
8
plt.plot(x, y)
5
6
Liste von Definitionen u.ä.
14.3
14.3.1
Editoren, IDEs
Editoren mit Unterstützung für Programmiersprachen
• Python-Dateien mit trivialen Editoren anfertigen? Notepad, textedit?
• Editor mit Unterstützung für Programmiersprachen
– Syntax: Formatierung, Highlighting, Einrückungen . . .
– Semantik: Verfügbare Funktionen, Klassen, Methoden, . . .
* Schwierig in dynamisch typisierten Sprachen
– Integration mit anderen Werkzeugen (Dokumentation, Debugger,
Tests, . . . )
• Ideal: Plattformunabhängig
14.3.2
Editoren, Beispiele – Open-source Beispiele
• VIM: kompakt, schnell, aber etwas kryptische Bedienung
• Atom: modern, Javascript-basiert und dadurch erweiterbar ; weniger
mächtig als Emacs
• Notepad++: Windows-only, aber angeblich trotzdem ganz gut
• Emacs: DER Editor für Erwachsene
– Lisp-basiert, dadurch erweiterbar
– Umfangreiche Sammlung an Modulen für alles mögliche
– GP1 wurde durch Emacs möglich – Org-mode
– Mit diversen Clones für unterschiedliche OS, z.B. Aquamacs
14.3.3
Emacs
Abbildung 14.2: Emacs thumbs
14.3.4
Editoren, Beispiele – Kommerzielle Beispiele
• SublimeText: OSX, aber recht bekannt
• Smultron: OSX, Neuauflage, vielleicht vielversprechend
Siehe auch: Übersicht Python-Editoren
14.4. Debugging und Testing
14.3.5
Integrated Development Environment
• Mehr als ein Editor, vereint weitere Werkzeuge in einem User Interface
(nicht notwendigerweise in einem Programm)
– Aber Grenze ist fließend
• IDEs typischerweise: sehr komplex, funktionsüberladen, komplizierter
Einstieg
– Sie sollen Programmier, nicht IDE-Bediener werden
– Hoher Einarbeitungsaufwand lohnt nur bei intensiver Nutzung
• Beispiele
– Kommerzielle: PyCharm (mit kostenloser Community Edition)
– Open-Source: Eclipse mit PyDev
– Weitere Beispiele: WingIDE, KommodoIDE, KDevelop, . . .
14.4
Debugging und Testing
14.4.1
Fehlersuche mit print?
• Kaum ein Programm wird fehlerfrei erschaffen
• Wie sucht man Fehler?
– Testfälle!
* Automatisiert testen?
– print – überall
– Noch mehr print
14.4.2
Aspekte der Fehlersuche
• Strukturiert Vorgehen?
– Leider wenig Literatur
– Aber Ideen hier und da; siehe z.B. code:union blog, codementor
blog, weitere Blog
• Werkzeug?
14.4.3
Aufwand der Fehlerbeseitigung
Abbildung 14.3: Aufwand der Fehlerbeseitigung
7
8
Liste von Definitionen u.ä.
14.4.4
Vorgehen: Basics
[Es passiert nichts unmögliches]
When you have eliminated the impossible, whatever remains,
however improbable, must be the truth.
Sherlock Holmes in The Sign of the Four
14.4.5
Vorgehen: Fragen stellen
Es geht nicht ist nicht hilfreich
• Fragen an sich selbst:
– Warum gehe ich davon aus, dass der Code nicht funktioniert?
– Was habe ich eigentlich erwartet? Warum?
* Auf welcher Granularitätsebene sollte ich das beantworten?
* Vielleicht habe ich die Spezifikation falsch verstanden?
– Was ist stattdessen passiert? Woher weiß ich das?
• Weitere Hilfsfragen:
– Fehlerverhalten eingrenzbar?
– Hat eine Änderung zu Fehlern geführt?
14.4.6
Vorgehen: Annahmen überprüfen
Annahmen überprüfen!
• Mein Code hat keine Schreibfehler; alle Variablen sind richtig geschrieben
– Typische Falle in dynamischen Sprachen!
• Verständnis der Schnittstelle benutzten Codes; insbesondere defaults
– Beispiel: list.pop hat einen ungewöhnlichen Default-Wert!
– Beispiel: Werden alle Parameter einer Funktion korrekt angegeben?
Fehler kann viel später im Code manifestieren
14.4.7
Vorgehen: Reproduzieren
Was muss ich tun, um den Fehler zu reproduzieren?
• Gibt es unterschiedliche Eingaben, Zustände, die zum gleichen Fehler
führen?
• Entscheidend bei der Dokumentation von Fehlern!
– Testfälle dokumentieren
14.4.8
Vorgehen: Erklären Sie Ihren Code!
• Erklären Sie, warum der Code funktioniert
– Und der Fehler eigentlich nicht auftreten kann
14.4. Debugging und Testing
• Einem Kommilitonen, der Großmutter, einer Quietscheente, einem Kaktus, . . .
14.4.9
Vorgehen: Grenze zwischen eigenem Code/Bibliotheken verstehen
• Die meisten Fehler macht man selbst :-(
• Wo ist der Übergang von eigenem Code in Bibliotheken? Was passiert
an der Stelle?
– Hier helfen debugger; siehe unten
14.4.10
Vorgehen: Annahmen sicherstellen (Assertions)
• Sie denken, Ihre Annahmen stimmen?
• Dann können Sie ja Test-Code einfügen, der das überprüft
• Einfache Möglichkeit: Assertions
– Schlüsselwort: assert(boolescher Ausdruck)
– Wenn Ausdruck wahr; weiter
– Wenn falsch, Exception
• Kann sehr schnell Fehler eingrenzen; insbesondere
– An Grenze zu Bibliothekscode: Vor und nach Aufruf
– In eigenem Code: Zu Beginn jeder Methode (haben alle Parameter
den erwarteten Wert?)
14.4.11
Vorgehen: Das Wissen der Alten
• Chancen stehen gut, dass man nicht der erste mit dem Problem ist
– Suchmaschine!
– StackOverflow!
* I wrote this program for my assignment and it doesn’t work.
– (Richtiges Füttern von Suchmaschinen wird eine Kernkompetenz
werden. . . )
Abbildung 14.4: Wissen der Alten
14.4.12
Vorgehen: Fixes
• Der Fehler ist gefunden
• Die Lösung ist offensichtlich
– Nur leider falsch. . .
9
10
Liste von Definitionen u.ä.
• Mindestens: Die Testfälle wieder ausprobieren!
– Und noch mehr Tests
14.4.13
Vorgehen: Erfahrung
Debugging ist erlernt
• und braucht Übung
• Noch viel mehr Übung als Programmieren
14.4.14
Ansätze: Was kann man tun?
Mit geeignetem Debugger:
• Programmablauf gezielt unterbrechen
– Programmzeile, Modul, Funktion
– Beim Entstehen einer Exception
• Was sind Variablenwerte an kritischen Stellen?
– Variablen modifizieren?
• Programm kontrolliert ausführen?
– In einzelnen Schritten?
– Bis zum nächsten Fehler?
– Zusätzliche Funktionen ausführen?
– Ablauf modifizieren? Monkey patching?
14.4.15
Debugger für Python
Eigenständig
• pdb: Eingebaut in Python selbst (Standard-Package)
• ipdb: Ähnlich zu pdb, aber bessere Shell
• pudb: Übersichtlich ohne GUI! Terminal/curses-basiert; schnelle Tastaturbasierte Navigation
• Netter Überblick in einem Blog
In Editoren/IDE integriert
Praktisch alle der oben genannten Editoren/IDEs können einen/mehrere dieser
Debugger integrieren und ansteuern – YMMV
14.4.16
14.5
Good debuggers help
Testen
14.5. Testen
11
Abbildung 14.5: Good debuggers help
14.5.1
Testfälle
• Schon zur Fehlersuche besprochen: Überlegen Sie geeignete Testfälle
für ein Programm/Funktion/Klasse
– Übliche Eingaben
– Randfälle: Leere Eingaben, Sonderfälle, fehlerhafte Eingaben, . . .
• Dokumentieren Sie Testfälle!
14.5.2
Automatisiert testen
• Von Hand testen: nützlich, aber beschränkt
– Menschen sind einfach zu faul dazu
• Automatisiert testen!
– Testfälle in einem Testprogramm festlegen
– Bei Änderungen am entwickelten Programm: Tests laufen lassen
• Das kennen Sie von den Hausaufgaben!
– Punkte werden durch ein solches automatisiertes Test-Framework
bestimmt
14.5.3
Test-driven design
Professioneller Ansatz:
• Erst die Tests schreiben
– Die scheitern am Anfang natürlich alle
• Nach und nach Funktion implementieren
– Immer mehr Tests werden erfolgreich sein
• Programm ist fertig, wenn Tests ok
14.6
Zusammenfassung
12
Liste von Definitionen u.ä.
14.6.1
Zusammenfassung
• Python: Installation des Interpreters und der Standard-Bibliothek meist
nicht schwer
• Für produktives Arbeiten
– Editoren mit Sprachunterstützung
– Debugger und Debugging-Disziplin
– Test-Frameworks und Test-Disziplin