[Python-de] [Langer, leicht ins OT driftende Sermon] Was mir an Python gefällt (war: Jahresendrant)

Gerson Kurz Gerson.Kurz at t-online.de
Wed Jan 1 12:31:40 EST 2003


Und wieder ein neues Jahr gebootet. Ich hoffe, auch euer morgendliches
chkdsk im Badezimmerspiegel musste keine unbedeutenden Fehler beheben ;)

Also auf ein neues. Stefan Schwarzer schreibt

> lies auch bitte den Artikel von Martin Fowler:
> http://www.martinfowler.com/articles/yetOptimization.pdf

Der Kern des Artikels scheint mir das Mantra "Das optimieren kommt erst,
wenn der Code sauber steht" zu sein. Was soll ich sagen: mir gefällt das
Mantra "viele heutige Programmierer haben das Optimieren verlernt" erheblich
besser. Und, genauso wie das Fowler-Mantra sich anekdotisch reichlich
belegen lässt, so könnte ich schmuckreich von bleischwerem Codebloat reden.

> Vielleicht in der Laufzeit, aber in der Entwicklung ...?

Ich würde sagen, genau das ist ein Knackpunkt: Die Sprache Python ist ein
>Traum für Entwickler<: übersichtlich, lesbar, mächtig, leicht zu benutzen,
riesige Standardlibrary usw. Gleichzeitig ist Python aber, zumindest was
Windows Nutzer betrifft, alles andere als ein >Traum für Endanwender<. Nicht
umsonst ist es eine Sprache, die eher für "Scripting"-Aufgaben in der
Administration verwendet wird denn für Endanwenderzeug.

So, bevor du jetzt zu einem wortgewaltigen alttestamentarischen Fluch über
Windows-Luser ausholst, möchte ich das näher ausführen:

Nimm als beispiel pserv.cpl. Das Tool hatte ich in C++ geschrieben, und ist
für reine Endanwender gedacht, als Ersatz für die langsame MMC. Da ist also
schonmal der Punkt: das Programm wird beworben für Leute, denen die
(tatsächlich unsagbar langsame) MMC zu langsam ist - das sind keine, die den
Punkt "Geschwindigkeit" hinten runter fallen lassen. Da die C++ Version
meine firmeninterne Library benutzt, kann ich den Quellcode nicht freigeben.
Ich habe das also in wxPython neugeschrieben, damit ich es OpenSource machen
kann. Das neuschreiben verlief auch wunderbar.

Ich habe aber bereits drei Rückmeldungen (von drei Leuten, die sich zu dem
Beta gemeldet haben, also von 100% in einer zugegeben nicht gerade umwerfend
großen Stichprobe), die mir sagen, daß die neue Version deutlich langsamer
sei als die alte. Sprich: Traum für Entwickler, zu langsam für den Enduser.
Der Enduser schert sich nicht darum, ob ich mir eine Art vergeistigten
Orgasmus an den Sprachfeatures geholt habe, er möchte ein schnelles,
einfaches Programm haben.

Dabei gibt es gar nicht mal soviel zu optimieren (du kannst aber gerne in
den Code reinschaun): das fängt damit an, daß die wxPython-Version 11 mb in
den Speicher reinnudeln muß (und relokieren, und das initialisieren von
wxPython usw.) bis überhaupt irgend etwas am Bildschirm erscheint, während
die C++ Version mit den NT native DLLs auskommt. Und die Geschwindigkeit
zeigt sich eigentlich primär in der Darstellung, du willst halt einfach die
Liste der Services sehen!

Stefan Schwarzer schreibt

> Wenn du einen "universellen" Interpreter verwendest, braucht der
> tendenziell  natürlich mehr Platz als ein spezialisiertes Programm,
> das nur die benötigten Funktionen linkt. Aber je mehr spezielle
> Programme du entwickelst und auslieferst, umso mehr "lohnt" sich
> das Python-System bei insgesamt gleicher Qualität.

Dazu mehrere Anmerkungen:

- Auf den meisten Linuxrechnern ist ein Python drauf, und, ich sage es mal
so: wer Linux benutzt, ist in der Regel auch gewillt, Versionskonflikte
selber zu lösen. (Ich sage nur: passende wxPython-Libraries "ziehen" usw.)
Das ist auf Windows nicht der Fall. Du hast ein ähnliches Problem wie mit
Java: Wer bringt schon die Motivation auf, sich die (korrekte!) Java-Runtime
runterzuladen, nur um ein blödes Applet zu sehen? Da nimmt der "Normalo"
doch lieber ein anderes Programm, das ohne das auskommt - es ist ja nicht
so, daß z.B. pserv das erste je geschriebene Programm ist, um die Services
anzuschauen.

- Du müsstest also, um ein simples Tool von mir zu benutzen, Python
runterladen und installieren (und zwar die richtige Version), wxPython (und
zwar die richtige Version) runterladen und installieren, und dann noch einen
Kommandozeilensetup für mein Tool ausführen (distutils). Und das, obwohl du
vielleicht gar kein Programmierer bist und einfach nur ein Tool haben
möchtest, um die NT Services & Devices besser verwalten zu können.
Vielleicht wolltest du es einfach mal ausprobieren, nicht ahnend, auf welche
Odyssee du dich eingelassen hast!

- Ich habe mich deshalb an Napyr versucht
(http://p-nand-q.com/e/napyr.html). Das ist ein erster Schritt, aber für
mein Gefühl immer noch zu umständlich, und: es ist mein privates Vergnügen.
Es gibt keine Standardlösung dafür, wenn also jemand ein wxPython-Programm
irgend eines anderen Autors haben will, hat er erneut das DLL-Problem.

Stefan Schwarzer schreibt

> Tut mir leid, falls das jetzt dumm rüberkommt, aber soweit ich
> sehe, ist Python vielleicht die falsche Sprache für dich. Wenn
> du mehr Kontrolle willst, dann nimm doch einfach C/C++. Python
> ist eben auf andere Prioritäten  zugeschnitten als C/C++, und
> ich fände es nicht vernünftig, ja, gerade absurd, Pythons Stärken
> (z. B. Garbage Collection und Exception Handling) für mehr
> Geschwindigkeit oder Low-level-Kontrolle zu opfern.

Also, ich denke, Pythons-Stärken liegen NICHT bei den zwei von mir absofort
so genannten UNBERÜHRBAREN. Ich habe mir deshalb mal die Mühe gedacht,
darüber nachzudenken, was genau mich an Python fasziniert. Ich bin auf vier
Punkte gekommen, die vielleicht nicht alle offensichtlich sind:

1) Das "Handling", der Aufwand, um ein Programm auszuführen
2) Eingebauten Datentypen wie string, list, dict
3) Die Syntax
4) Die Standard-Bibliothek

Zu 1. Dazu muß ich ein bisserl ausholen.

Ich habe seit Jahren viele kleine Testprogramme geschrieben. Mit viele meine
ich: In der Firma, in der ich jetzt seit 6 Jahren bin, befinden sich über
1100 Projekte auf meinem Rechner - ehrlich! Gut, viele haben tragende Namen
wie "TESTMENU_ELENDER_SCHEISSDRECK" (wie man am Namen unschwer erkennen
kann, ein OS/2 Projekt), oder "CreateSchmarrnDat". Mit Testprogramm meine
ich: ausprobieren, wie funktioniert die Funktion X des Betriebssystems / der
Klassenbibliothek etc.; Dateien auswerten, einen Parser schreiben, und all
das, du wirst lachen, C++. Ich habe auch jede Menge kleine Tools für
Entwickler / Administratoren geschrieben - eine tatsächlich verschwindend
kleine Auswahl findest du z.B. hier
http://p-nand-q.com/e/other_downloads.html. Schau übrigens mal auf die Größe
der Downloads...

Also ein Projekt in C++. Das bedeutet, zumindest beim DeveloperStudio, nicht
nur die Quelldatei, nein nein, man braucht auch zwei Projektdateien (.dsp,
.dsw), einen precompiled header weil sonst das übersetzen zu lange dauert
(also precomp.h und precomp.cpp), und dann das Projekt laden, ändern,
übersetzen. Dann *meine* Compilereinstellungen auswählen (du erkennst die
"alte schule", wenn sie die "optimize" mal grundsätzlich ausmacht, weil
damals, bei Glockenspiel, als alles so furchtbar schlimm war). Dann muß der
Compiler bei jedem dieser 1100 Projekte zumindest einmal die precomp.cpp
übersetzen, d.h. die ganzen Windows-Header (und meine Standard-C++-Library)
reinladen; und die Windows-Header sind *riesig*, d.h. precomp.cpp dauert
grundsätzlich 2-3 Sekunden. Und das, obwohl sich die Header vielleicht
einmal im Jahr ändern! Dann hast du das Projekt übersetzt, öffnest du eine
Konsole im Debug-Verzeichnis (10 MB an Objekten wg. dem riesigen precomp.pch
und der .pdb, dabei ist das exe selber ganze 20k groß), und testest das,
switchst wieder zurück ins DevStudio usw. usf.

Ich habe mir sogar einen eigenen Wizard geschrieben, der C++ Projekte anhand
von Templates erstellt, mit meinen Compileroptionen, meinen precomps, das
Devstudio öffnet. (Die einzige Compileroption, die bis heute ich nicht
setzen kann, ist "Build browse information", was Quelle unzähliger Flüche
ist: Die Browse Information ist mal ein gutes Feature, und es ist natürlich
buggy ohne ende im Devstudio).

Fazit: Du hast einen riesen Overhead, wenn du nur mal z.B. ausprobieren
willst, was die GetSystemInformation-Funktion bei einem speziellen Parameter
für eine Antwort liefert. (Nicht zu vergessen der Plattenplatz, die
precomp.pch gibts in Debug und Release, also maximal über 2200 mal auf der
Platte! Ich habe natürlich ein (C++) Tool geschrieben, das rekursiv alle
Verzeichnisse durchläuft und alle Debug/Release-Objekte löscht)

Dagegen Python: ich schreibe ein Script im guten SciTe, ich drücke F5 und
der gute SciTe führt es aus, fertig! Eine einzige Datei auf der Platte! Nix
Overhead! Ich liebe es! (Mein Python-Scriptdir enthält übrigens bereits 2832
Dateien, wobei zugegeben viele .pycs und Sicherungskopien dabei sind, das
ganze nach Datum sortiert. so habe ich z.B. im Juli 2001 folgende Scripts
erstellt: addp.py, bored.py, GetUniqueDayIndex.py, patch-scintilla.py,
sample_bored.py, Script1.py, TestClass.py, WinOnCD.py wobei ich zugegeben
von keinem dieser Tools noch weiss, was sie gemacht haben. Ah, ich sehe,
Script1.py markiert über COM einen Block im geöffneten Fenster im Developer
Studio).

Völlig unabhängig von "wie einfach kann ich etwas in der Sprache x
ausdrücken" - das Handling ist in Python erheblich einfacher als in C/C++ -
wenn man "meinen" Arbeitsstil hat.

<einschub>
Mir ist beim Schreiben dieser Mehl die Idee für eine Art C++ Scripting
gekommen: Man sollte ein tool schreiben, das folgendes macht:

- Sourcecode einlesen und ggf. erweitern (z.B. braucht man für diese Zwecke
kein explizites main())
- daraus im Hintergrund ein Projekt erstellen (precomps existieren bereits),
- compilieren,
- das erzeugte EXE ausführen.
- (falls das EXE bereits existiert und neuer ist als der Source, kann man
die Schritte 2+3 überspringen).

Wenn man es schafft, das ganze auch "reentrant" zu machen (d.h. mehrere
solche "Scripten" können gleichzeitig übersetzt/ausgeführt werden), hätte
man in mir vermutlich einen "heavy user" ;)
</einschub>

----------------------------- (Denkpause) ---------------------------

Das also war Punkt 1, kommen wir zu Punkt 2: Eingebauten Datentypen.

Es gibt ja in C++ die STL. Ich hasse sie. Soviel dazu.

Nein ehrlich, vielleicht bin ich ja einfach nur ein misstrauischer Grantler,
aber wenn ich mir die Sourcen der STL anschaue, kommt mir das kalte Grausen.
Wer, bitte schön, versteht auf Anhieb, was

template<class _II, class _OI, class _Ty> inline
	_OI funktionsname_gesnippt_damit_das_raetsel_bleibt(_II _F, _II _L, _OI _X,
_Ty *)
	{_Ty _V = *_F;
	for (*_X++ = _V; ++_F != _L; )
		if (!(_V == *_F))
			_V = *_F, *_X++ = _V;
	return (_X); }

macht? Und: das soll Production Code sein!

Oder, einfach mal so: hast du schonmal in den Konstruktor std::string
reingesteppt? Abenteuer harren deiner! Spiel, Spaß und Spannung für die
ganze Familie!

Abgesehen davon, daß, als ich das letzte mal nachgeschaut habe, der Code,
den der Compiler (nicht nur M$, sondern z.B. auch der VisualArschlangsam für
OS/2) hierfür (oder für Templates allgemein) generiert, GRAUENHAFT(TM) ist.
(Die gewundene Satzkonstruktion von gerade eben kann man durchaus als
sprachliches Äquivalent für die gewundenen Templatekonstruktionen der STL
nehmen).

Ich benutze in der Regel meine eigene Library, die zwischen Win32 und OS/2
(und inzwischen, zumindest was die Nicht-GUI-Teile betrifft, auch
Linux)-kompatibel ist. Aber: Ich kann in Python schreiben

a = ["TSV",1860]

Genau dieses in C++ auszudrücken ist nur mit erheblichem Mehraufwand
möglich; weil char* und int zwei "inkompatible" Datentypen sind.

Zu 3: Wer meine Webseite kennt, wird wissen, daß ich grundsätzlich bewandert
bin in den Freuden der abseitigen Syntaxqualen. (Wer nicht, lese
http://p-nand-q.com/e/java2k.html). Gerade deshalb bewundere ich die
Python-Syntax, die mir tatsächlich sehr "natürlich" erscheint. Das viel
geschmähte Einrücken fand ich sofort intuitiv richtig; im allgemeinen ist es
in Python fast immer möglich, einen Ausdruck klarer und kürzer zu schreiben
als in C/C++. Das ist ein Wert an sich, und ich erkenne ihn voll an. Ich
kann nur wiederum auf die STL verweisen, wie code NICHT ausschauen sollte.

Zu 4: ohne worte, da selbserklärend.

Christian Tismer schreibt jetzt:

> p.s.: Gerson, ganz vom aktuellen Python abgesehen fände
> ich es durchaus interessant, ein "Ptn" zu machen: Ein
> total abgespecktes Minimal-Python mit weniger Features
> als 1.5.2, sozusagen spartanisch aber aus heutiger Sicht.

Hey, genau das würde ich mir auch wünschen! Ich wäre auch sofort bereit,
dabei mitzuhelfen, so es mir den Zeitlich und von meinen Möglichkeiten
gesehen her möglich ist. (Ich fahre am Samstag erstmal für zwei Wochen in
den Urlaub, aber dann...)

Hast du schon nähere Pläne dazu? Genauer, hast du schonmal überlegt, welche
Python-Features Ptn-würdig wären, und welche nicht?

Ciao,
Gerson





More information about the Python-de mailing list