Das deutsche Python-Forum

Ein interessanter Vortrag, der nicht nur eine interessante Bibliothek für HTTP-REST-Operationen zeigt, sondern grundsätzliche Probleme von Python diskutiert und auffordert, sich an http://docs.python-guide.org/ zu beteiligen.

Hier gibt's sowohl die Folien als auch den Audio-Track: https://github.com/kennethreitz/python-for-humans

Der gute Mann hat IMHO recht: In einer Sprache, die stolz auf ihre "import this"-Philosophie ist, sollte es nicht ein halbes Dutzend verschiedene Wege geben, Python zu installieren, Module zu installieren, XML, HTTP oder Testing zu betreiben usw. Beim Zuhören kam mir der Gedanke, dass vielleicht der große Vorteil von JavaScript ist, dass diese Sprache keine fertige Klassenbibliothek hat. Python schleppt hier Funktionen mit, die seit vielen Jahren schon nicht mehr "best practice" sind, doch Alternativen sind schwierig, weil es einerseits keinen guten Weg gibt, neue Module zu installieren und vor allem auch wieder zu deinstallieren und andererseits die Dokumentation meist auch immer noch auf die veralteten Module verweist.

Somit ist die Python-Guide-Initiative sicherlich ein guter Weg, doch auch hier wagt man nicht, nur den einen Weg zu beschreiben. Für OS/X wird zwar empfohlen, python und pip über Homebrew zu installieren, dennoch folgt noch ein Abschnitt "compiling from source" und obwohl erwähnt wird, das "easy_install" gegenüber "pip" deprecated ist, wird's dennoch installiert. Und komischerweise wird unter Linux mit dem Argument, 2.7 wäre ja schon unter Ubuntu vorhanden, dann eben Python 3.2 installiert. Nanu?

Stefan

also bei aller berechtigten Kritik an Python - das voellige fehlen von irgend einer Standardbibliothek in JS als Vorteil zu definieren kann's doch auch nicht sein. Frei nach dem Motto "ein Feature ist kompliziert - also erlauben wir einfach nicht, dass man sowas mit der Sprache macht".

JS wird noch ganz schoen in's Rudern kommen, wenn groessere Web-Apps als die heute mit komplexen Abhaengigkeiten und dem Wunsch nach lokalem Code-Caching Realitaet werden. Natuerlich hat es da den konzeptionellen Vorteil, im Grunde immer im Browser als Runtime zu leben, womit sich dann keine systemweiten Installationen ergeben. Aber Netzwerkzugang als Vorraussetzung geht halt auch nicht immer.

Alte Muehlsteine mitzuschleppen mag nerven - und Python3 ist ja zB der Versuch, da aufzuraeumen. Mit entsprechenden Problemen.

Aber erst gar nicht mahlen zu koennen finde ich deutlich bloeder. Fuer jedes JS-framework wieder neu lernen zu muessen, welchen Prototyping-Erweirterungsansatz das nun waehlt, oder die x-te Implementation von bind-this-to-a-class-method zu entdecken. Wenn's denn ueberhaupt eine gibt, und man nicht einfach selbst closures schreiben muss....

Ad "There's only one way to do it': Sicher ist das ein guter Vorsatz, hat aber viele Probleme und nicht das geringste dabei ist die Weiterentwicklung von Ideen, was eben doch besser durch Konkurrenz als durch Gremien passiert.

Das ist auch ein wenig inkonsistent mit dem Wegwerfen der Stdlib: Wenn es nur einen Weg gibt, warum nicht gleich einbauen? Wenn er nicht eingebaut ist, wer hat dann das Sagen was der richtige Weg™ ist?[1]
Sicher ist das Pflegen der Stdlib PITA, aber fuer Anwender ist sie ein Segen.
Was hier helfen wuerde waere eine Stdlib ausserhalb der Stdlib, gab es nicht einmal Bestrebungen die Stdlib austauschbar zu machen?

[1] Generell sollte man das nicht zu ernst nehmen: "Die einzig richtige Wahrheit" ist was fuer Religionen und nichts fuer gesunde Menschen.

„There's only one way to do it“ hat ja auch nichts mit Python zu tun. Das Zen sagt „There should be one-- and preferably only one --obvious way to do it.“

Zwischen „es gibt nur einen Weg“ und „es sollte einen — und vorzugsweise nur einen — offensichtlichen Weg geben“ ist schliesslich ein Unterschied. Manchmal gibt es mehrere und manchmal auch nicht nur einen offensichtlichen Weg.

cofi hat geschrieben:Was hier helfen wuerde waere eine Stdlib ausserhalb der Stdlib, gab es nicht einmal Bestrebungen die Stdlib austauschbar zu machen?

Stdlib außerhalb der Stdlib? Meinst du nicht vielleicht eher das Trennen zwischen Builtin-Funktionen und mitgelieferten Modulen? Letzteres ist wohl das, was man am ehesten als Stdlib bezeichnen würde.

Übrigens, Erwähnung findet die von dir genannte Überlegung z.B. in einem etwas älteren Artikel im Python Insider Blog. Wie weit das Ganze fortgeschritten ist, weiß ich allerdings nicht.

Die stdlib ist zum größten Teil kaputt und unbrauchbar. Klar gibt es re, itertools und collections aber dann hört es schon auf mit Dingen die man ernsthaft als gelungen bezeichnen kann. Eine seperate stdlib wie bei Haskell wäre schon sehr hilfreich, ich denke da nur an datetime und Zeitzonen.

Naja, als kaputt würde ich sie nicht unbedingt bezeichnen. Das Nonplus-Ultra hinsichtlich Fähigkeiten und Design stellen viele der mitgelieferten Module aber in der Tat nicht dar. Das stimmt wohl.

Man darf nur niemals den Fehler machen und sich für die (CPython-)Implementierung eines Moduls interessieren, dann geht das mit dem Blutdruck auch in Ordnung

@derdon: Wen interessiert die Implementierung, solange das Modul tut, was man von ihm verlangt?

lunar hat geschrieben:@derdon: Wen interessiert die Implementierung, solange das Modul tut, was man von ihm verlangt?

Denjenigen, der sie ggf nach 2 Jahren überarbeiten muss.

lunar: Du beantowrtest die Frage ja schon in deinem Nebensatz "solange das Modul tut, was man von ihm verlangt". Wenn ich Probleme mit der Benutzung eines Moduls habe oder ich einfach aus Neugier wissen möchte, *wie* ein bestimmtes Problem gelöst wird, dann schaue ich in den Quellcode. Außerdem dachte ich anfangs in meiner leichtgläubigen Naivität¹, dass der Code von der stdlib vorbildlich, PEP8-konform und allgemein so sein sollte, dass ich davon lernen könnte. Aber dem ist nicht so.


¹ ein Pleonasmus, ich weiß …

Tja, hätten die Entwickler mal vorher ins Python-Forum geguckt.