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

Stefan Schwarzer sschwarzer at sschwarzer.net
Wed Jan 1 21:38:28 EST 2003


Hallo Gerson,

(an die anderen: Wenn's zu arg off-topic wird, bitte Bescheid sagen :-) )

es kann sein, dass ich dich an einigen Stellen missverstehe, weil ich von Windows-
Systemprogrammierung keine Ahnung habe. Ich versuche trotzdem, eine sinnvolle
Antwort zu schreiben. :-)

Gerson Kurz wrote:
>> 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.

In dem Artikel geht es nur um Geschwindigkeitsoptimierungen. Die dort beschriebene
Vorgehensweise kümmert sich nicht um "Codebloat", weil es nicht Thema des
Artikels ist. Man kann Codebloat sicher durch Refaktorieren erheblich eindämmen,
aber das ist eher orthogonal zum Inhalt des Artikels. Das heißt, Refaktorieren
kann und sollte man auch dann laufend, wenn man sich die Geschwindigkeits-
optimierungen für später aufhebt.

Wir handhaben es auch in unserem Python-Projekt so, und frag' mich nicht, wieviel
redundanten Code ich schon ausgemistet habe. ;-)

>> 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.

Hat das nicht hauptsächlich damit zu tun, dass Python nicht zum Standard-
Lieferumfang der Windows-Versionen gehört? ;-) Nun muss man als Entwickler
entweder alle benötigten Bibliotheken (ähnlich wie du mit Napyr) mitliefern
und -installieren oder dem Anwender zumuten, Python getrennt zu installieren.

Das wäre bei jeder Laufzeitumgebung, die nicht direkt mit dem Windows-Basissystem
installiert wird, das gleiche, oder? Gleichgültig, welche Eigenschaften die
Sprache hat. Natürlich ist die Laufzeitumgebung bei einer funktionsreichen
Programmiersprache auch umfangreicher.

> So, bevor du jetzt zu einem wortgewaltigen alttestamentarischen Fluch über
> Windows-Luser ausholst,

Nein, tue ich nicht. Das ist nicht meine Art. :-)

 > 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.

Schon klar. Und du meinst, das ist mit Python nicht zu schaffen?

> 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,

Das ist doch eher ein Problem von wxPython, nicht eines des Python-Standardsystems?
Du könntest vielleicht ein anderes GUI-Toolkit nehmen.

 > 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!

Schreib' doch einen Python-Wrapper für die Windows-nativen Funktionen, die du
brauchst. (Vielleicht ist das jetzt zu simpel gedacht.)

>> 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 gebe dir völlig Recht, dass das sehr unschön ist. Zu der Zeit, wo ich noch
unter OS/2 programmiert habe, habe ich mir über das Thema ebenfalls Gedanken
gemacht. Schließlich habe ich beschlossen, mich nicht um eine "automatische"
Installation eines Python-Systems zu kümmern, sondern es einem potenziellen
Anwender meiner Programme selbst zu überlassen, Python zu installieren. (Geht
inzwischen immerhin auch mit GUI-Installation wie unter Windows. :-) )

> - 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.

Wie weit bringen dich Systeme wie py2exe? Hilft das?

Ich nehme an, dass es Vertreiber kommerzieller Windows-Programme einfach so
machen, dass sie immer alle benögten DLLs mitliefern, egal, ob sie schon auf
dem System sind oder nicht. Das ist wohl nicht besser als das, was du beschreibst. ;-)

Was die "Standardlösung" angeht: Es käme mir etwas seltsam vor, wenn es "nur" um
eine "Standardlösung" zur Installation von Python-Programmen ginge. Eher ist eine
allgemeinere Lösung gefragt (wie bspw. die Paket-Systeme von *BSD oder *Linux).
Schließlich erstreckt sich das Problem ja nicht nur auf den Python-Interpreter und
die Standard-Module, sondern auch auf "externe" Programmteile wie bei dir die
wxPython-DLL.

> Also, ich denke, Pythons-Stärken liegen NICHT bei den zwei von mir absofort
> so genannten UNBERÜHRBAREN.

*lach*

 > 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...

Ja, hübsch klein. Aber ein "fairer" Vergleich wäre doch wohl eher mit dem
Quelltext der gelieferten Python-Skripte/Module und nicht mit der ganzen
Python-Installation. Sonst müsstest du bei deinen C(++)-Programmen auch einen
Teil der Windows-Standardbibliotheken, Laufzeitbibliotheken zu deinem Compiler
und Ähnliches mitrechnen.

 > [Grausame Beschreibung zur C++-Entwicklung gelöscht]
 >
> 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.

Das war ebenfalls der Grund für meinen "Umstieg" von C++ zu Python.

> <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>

Irgendwo habe ich mal was von einem C-Interpreter gelesen. Vielleicht wäre das
ein Startpunkt.

> ----------------------------- (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!

Das finde ich auch sehr abschreckend. Wenn du mich fragst, sieht das nach "über
Bord gegangener" Optimierung aus.

> 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!

;-)

> 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.

Ich verstehe dich und stimme dir völlig zu. :-)

Viele Grüße
  Stefan





More information about the Python-de mailing list