Python wird immer komplizierter

[gerold]

Hallo!

Ich möchte mal etwas los werden. Auch wenn ich damit wohl alleine da stehe, aber ich finde, dass alles was Python komplizierter macht, nicht in Python rein gehört.

Ich habe das schon mal mitgemacht. Aus Visual Basic 6 wurde Visual Basic.NET. Alles wurde komplizierter. Keiner wollte VB.NET, aber es wurde einem einfach von Microsoft aufgezwungen. Viele Programmierer (ich auch) wanden sich damals von Visual Basic ab.

Und bei Python beobachte ich ähnliche Züge. Zwar nicht so schlimm, aber imerhin. Anscheinend ist es den Python-Entwicklern längst nicht mehr so wichtig, dass Python einfach bleibt. Statt vorhandene Module zu verbessern und gute, neue Module hinzuzufügen, wird an der Sprache gedreht. Man muss ja unbedingt den anderen Programmierern imponieren.

Leute, die komplizierte Einzeiler schön finden, sollten nicht an Python programmieren.

Die für mich schlimmsten Negativbeispiele sind Dekoratoren und Metaklassen. Was soll das? Anstatt am Ende einer Funktion eine andere Funktion aufzurufen, wird bei der Verwendung von Dekoratoren die ganze Funktion an eine andere Funktion (Dekorator) weitergegeben, die dann irgendetwas damit anstellen soll???

Das kommt mir immer so vor wie über den Arsch eine Mandeloperation durchzuführen. Ich habe noch keinen Fall entdeckt, der nicht auch ohne Dekoratoren schön lösbar gewesen wäre.

Schade, dass ich mit dieser Meinung alleine da stehe. Denn sonst hätte sich schon längst ein anderer über diese unnötigen Verkomplizierungen bzw. Veränderungen aufgeregt.

Aber es geht ja noch weiter: ``print`` z.B. wird zu einer Funktion. Warum? Weil sich manche einbilden, dass man das unbedingt überschreiben können soll. Warum wird es nicht so gelassen wie es ist? Warum dieses ständige Umlernen?

Wenn ich ein "print" brauche das nicht so wie das derzeit vorhandene "print" arbeitet, dann schreibe ich eine Funktion und nenne sie "printX" oder "printY". Egal wie! Die Funktion muss doch nicht unbedingt "print" überschreiben! Aber dafür darf man jetzt bei jedem "print" ein Klammernpaar mit angeben -- super! Was macht das für einen Sinn? Aber egal. Statt dass man nach ein paar Jahren endlich sagen kann, dass man *Python-Profi* ist, muss man genauer differenzieren. Man kann nur sagen, dass man *Python 2.0-2.4 Profi* ist. Python 3.0 muss man ja wieder neu lernen. Wenn man überhaupt möchte. Wer weiß was alles in Python 3.0 verkompliziert wurde. Wenn man dann nicht auf die *neuen* Techniken eingeht, dann ist man nicht cool genug.

Aber wenn ich mal ein paar Funktionen statt in einem eigenen Modul in einer Klasse zusammenfassen möchte, weil das Programm damit einfacher und durchschaubarer wird, dann werde ich ausgelacht. Danke!

lg
Gerold

[BlackVivi]

Das ist mir im letzten halben Jahr auch gewaltig aufgefallen, Gerold... Ich habe mich zu Python gewandt, weil Java, C(++) und die .net Geschichten so gigantisch, unübersichtlich und kompliziert wirken. Bei Python ist alles klar, ich habe von Anfang an verstanden, was was ist. Ich konnte sogar Quelltexte und ganze Projekte mir anschauen und verstehen.

Aber bei PEP3000 sieht das alles wieder schwieriger aus. Ich hoffe, dass Python seinem Zen treu bleibt...

[Rebecca]

Huiuiui, was ist dir denn ueber die Leber gelaufen?

Aber es geht ja noch weiter: ``print`` z.B. wird zu einer Funktion. Warum?

Damit ich endlich help(print) eintippen kann. Mit den Aenderungen in Python 3.0 habe ich mich noch kaum beschaeftigt, aber die Sache mit dem print gefaellt mir. Statements sollten schon fuer besondere Dinge vorbehalten sein (if, def, class, import...), alles andere sollten meiner Meinung nach Funktionen sein.

Warum wird es nicht so gelassen wie es ist? Warum dieses ständige Umlernen?

Das ist ja nun nicht wirlich ein Argument. Bisher hat man ja immer Wert auf Rueckwaertskompatibiltaet gelegt, dass man bei 3.0 mal einen Schnitt zieht, finde ich in Ordnung. Sonst haeufen sich die kleinen Suenden der Vergangenheit an und muessen immer mitgeschleppt werden, was einem klaren Design nicht gerade zutraeglich ist.

Aber wie gesagt, mit Python 3.0 habe ich mich bisher kaum beschaeftigt.

[EnTeQuAk]

Also ich muss einfach mal gegen dich sprechen. Ich kennen den aktuellen Entwicklungsstand von Python 3.0 nicht, denke aber, das man da nicht unbedingt viel "neu lernen" muss.

Das 'print' eine Funktion ist, finde ich durchaus richtig, auch wenns am Anfang komisch ausschaut. Ich glaube bei dieser Entscheidung stand aber auch nicht die Möglichkeit des Überschreibens im Vordergrund, sondern eher die klarere Syntax. Ich weiß grad nur nicht, ob andere Statements wie 'assert' das auch betrifft. Das währe dann jedenfalls nur Konsequent in meinen Augen.

Die für mich schlimmsten Negativbeispiele sind Dekoratoren und Metaklassen. Was soll das? Anstatt am Ende einer Funktion eine andere Funktion aufzurufen, wird bei der Verwendung von Dekoratoren die ganze Funktion an eine andere Funktion (Dekorator) weitergegeben, die dann irgendetwas damit anstellen soll???

Ich finde Dekoratoren gar nicht schlimm. Zumindest, wenn man sich einfach einprägt das

Code: Alles auswählen

@my_decorator
def my_function():
    #...

gleichzusetzen mit

Code: Alles auswählen

my_decorator(my_function)

Was ich allerdings letztens dank mitsuhiko lernen durfte, ist das es einen großen Unterschied zwischen '@my_decorator' und '@my_decorator(*args)' gibt. Zumindest was die Definition des Dekorators geht. Wenn mans mal begriffen hat, ists aber gar nicht schlimm.


Metaklassen muss ich sagen, habe ich bisher auch kaum benutzt. Jedoch wo ich sie benutzt habe, war ich recht froh das es sie gibt.


Was ich allerdings hoffe, das sich bei dem großen Sprung auf Python3.0 auch gleich die Bibliotheken endlich PEP08 komplett folgen. Das hat aber recht wenig mit diesem Thema zu tun.


Aber ich finde, das ist alles Geschmackssache. Ich finde es jedenfalls gut, das man mit Python sehr einfache als auch Komplizierte Sachverhalte entsprechend der Komplexität darstellen kann.

MFG EnTeQuAk

[gerold]

Huiuiui, was ist dir denn ueber die Leber gelaufen?

Hallo Rebecca!

Du hast schon recht damit. Ich habe seit ein paar Tagen immer wieder Fieber- und Schüttelfrostschübe. Bei jeder Bewegung des Kopfes glaube ich, dass mir die Adern im Kopf platzen. Und wegen der vielen Aspirin, die ich in den letzten Tagen genommen habe, ist mir andauernd schlecht. Und im WC bin ich Stammgast.

Es könnte also wirklich *daran* liegen, dass ich nicht so gut gelaunt bin. Das kann ich selber nicht so richtig beurteilen.

Vielleicht schaffen es ja eure Statements zu diesem Thema, mich wieder etwas aufzuheitern.

lg
Gerold

[Leonidas]

Hallo gerold,

ich glaube du findest jetzt nur wenige Leute die deine Meinung teilen Die "Verkomplizierung" ist mir auch aufgefallen, aber trotzdem finde ich, dass viel sinnvolles dazu kam und kommt.

Die Dekoratoren finde ich gar nicht so schlimm, obwohl ich zugebe, dass ich deren Syntax schlicht hässlich finde (j2-Syntax wäre besser, aber das ist ja schon entschieden). In Python 3 gibt es zudem noch Klassendekoratoren. Man kann durchaus Dekoratoren verwenden, um Code ganz simpel zu vereinfachen. Zum Beispiel diese publish-Dekoratoren in CherryPy und TG - sind doch eigentlich ganz praktisch, so muss man die Funktionen die öffentlich aufrufbar sind nicht extra wo anders registrieren sondern direkt dort wo man die Funktion definiert. Oder das Event-Handling in PyDispatcher/Louie. Irgendwer hat mal gesagt, dass die Syntax dazu geführt hat, dass die Dekoratoren einen Schub bekommen haben, so dass sie nun viel eher verwendet werden, als früher, ohne syntaktischen Zucker.

Metaklassen sind noch eine andere Sache. Die gibt es schon seit einer Ewigkeit, und wenn man sie nicht kennt dann ist die Sache ganz einfach - man braucht sie nicht. Ich nutze sie auch sehr, sehr selten. Aber wenn du dir die ORM-Layer anguckst dann wirst du mir sicherlich zustimmen, dass der Code den Elixir zur Deklaration von Datenbankobjekten verwendet doch sicherlich einfacher und eleganter ist als der "rohe" SQLAlchemy-Code. Man kann einige Dinge auch schon recht elegant über den "echten" Konstruktor `__new__` machen. Den habe ich erst letztens verwendet, um mit Klassen Funktionen besser emulieren zu können (das wäre zwar nicht nötig gewesen, aber so sind sie wesentlich angenehmer zu Nutzen, wer sie aber als Klassen nutzen will kann das immer noch machen).

Was ich eher problematisch finde sind relative Importe, meinetwegen auch das `with`-Statement (obwohl wenn man es sich mal genauer ansieht es doch Klasse ist und man sich wundert warum es das nicht schon länger gibt), functools etc.

Python 3 versucht eben viele Dinge die Sprachpuristen nicht gefallen auszuräumen. Ich mag Sprachen die so wenige "Warts" wie möglich haben, es erfordert weniger Denken, es ist schlichtweg logischer. Da ist das `print`-Statement genau so ein Problemfall.

Ich weiß nicht, was du mit komplizierten Einzeilern meinst? Das was ich manchmal konstruiere? Bedenke, dass ich das auch oft einfach nur zum Spaß tue und so etwas nicht in "richtigem" Code verwenden würde. Aus einfachen Zweizeiler hingegen einfachere Einzeiler zu machen ist doch auch in Ordnung. Mit LCs sind for-Schreilen oft genau so einfach zu lesen. Wer komplizierten Code nicht kommentiert ist natürlich blöd dran, aber Code kommentieren ist echt das mindeste.

@EnTeQuAk: Ich habe letztens auch eine Dekorator geschrieben und ja, Dekoratoren mit Parametern sind vergleichsweise umschön zu schreiben, weil du nested Functions brauchst, die von der äußeren Dekoratorfunktion zurückgegeben werden muss. Das Vorgehen ist eigentlich verständlich, aber besonders schön finde ich es auch nicht. Jedoch ist es nötig, um die @-Dekorator-Syntax kompatibel zur alten Decorate-after-Definition-Syntax ist.

[BlackJack]

Der VB->VB .NET-Vergleich hinkt IMHO. Da wurde nicht VB weiterentwickelt, sondern "gewaltsam" an das .NET-Framework angepasst.

Dekoratoren sind nur syntaktischer Zucker und dazu gedacht, dass man am *Anfang* der Funktion schon sieht, dass sie verändert wird. Ohne Dekorator versteckt sich diese Information *hinter* der Funktionsdefinition.

Code: Alles auswählen

    # Mit Decorator:
    @decorate
    def method():
        pass
    
    # Ohne Decorator:
    def method():
        pass
    method = decorate(method)

Wenn ``pass`` etwas länger ist, kann man die Modifikation der Methode schnell mal übersehen. Ist das wirklich so kompliziert?

Am Ende von `method()` eine andere Funktion aufzurufen ist nicht das gleiche wie das "Dekorieren", ob nun mit oder ohne spezielle Syntax. Die Funktion, die zurückgegeben wird, kann sowohl vor als auch nach dem Aufruf der gekapselten Funktion etwas tun. Und die `decorate()`-Funktion kann auch noch mehr machen als nur die gekapselte Funktion zurückgeben. Zum Beispiel die Methode irgendwo registrieren. Wird in Webframeworks gerne gemacht und ich denke da erhöht das die Lesbarkeit des entsprechenden Quelltextes.

Bis auf die spezielle Syntax gibt's diese Komplexität schon so lange wie Funktionen "first class objects" sind und es Closures gibt. Auf beides würde ich nicht verzichten wollen. Bin allerdings auch ein Fan von funktionaler Programmierung und habe keine Angst vor Funktionen höherer Ordnung.

Metaklassen sind AFAIK ein Abfallprodukt von "new style classes", die zur Implementierung derselben sinnvoll waren und nun auch Otto-Normalprogrammierer zur Verfügung stehen. Ist letztendlich auch nur konsequent ─ wenn Objekte einen "Bauplan" haben, der sich Klasse nennt und Klassen auch Objekte sind, liegt es nahe auch "Baupläne" für Klassen zu haben.

In Io wird das noch etwas weiter getrieben, da verschwindet die Grenze zwischen Klasse und Objekt fast völlig. Es gibt keine ausgezeichneten Klassen sondern nur noch Objekte und jedes davon kann die Rolle einer Klasse einnehmen. Das macht die Sprache IMHO sowohl konzeptuell als auch praktisch wesentlich einfacher und nicht komplizierter.

Ich denke beides, Funktionen höherer Ordnung und Metaklassen, sind gar nicht so kompliziert. Die Probleme liegen eher im festgefahrenen Denken von Programmierern, die es gewohnt sind eine harte Grenze zwischen statischem Code (Funktionen, Klassen) und dynamischen Daten zu ziehen. Der Gedanke Funktionen oder Klassen aus anderen Funktionen oder Klassen zur Laufzeit zu neuen Funktionen zu kombinieren oder Klassen zu verändern ist einfach fremd. Das gleiche mit Listen oder anderen Objekten (also andere als Funktionen oder Klassen ) zu machen ist dagegen völlig normal.

Ob die Umwandlung von ``print`` in `print()` nun wirklich so kompliziert ist!? Ist letztlich eine Vereinheitlichung. Du fragst warum muss `print()` unbedingt eine Funktion sein, andere fragen sich, warum muss es unbedingt den Sonderstatus einer Anweisung haben? Müsste man sich bei `input()`/`raw_input` dann nicht auch die Klammern sparen können? Ich glaube nicht, dass mich die zusätzlichen Klammern stören werden, hatte aber schon Fälle, wo ich mich ärgerte, dass man ``print`` nicht in einer ``lambda``-Funktion verwenden kann.

Es gibt doch auch Veränderungen die einiges Vereinfachen. Die ``with``-Anweisung zum Beispiel. Es war nie einfacher Dateien oder Locks *sicher* zu handhaben. Wenn man mal in das PEP schaut wie der äquivalente Code ausschaut, muss man doch zugestehen, dass man selten bis nie wirklich sauber mit Dateien gearbeitet hat, was das Zusammenspiel Ausnahme und schliessen der Datei angeht.

Und ElementTree macht den Umgang mit XML einfacher als die SAX- und DOM-Module.

@BlackVivi: Wenn man sich die Enwicklung bei C++, also C++0x anschaut, kann Python noch um einiges komplexer werden ohne C++ ein zu holen.

@EnTeQuAk: ``assert`` ist etwas besonderes in dem Sinne, dass der Compiler diese Anweisung komplett ignorieren darf.

Nochmal @gerold: Gute Besserung!

[BlackVivi]

@BlackVivi: Wenn man sich die Enwicklung bei C++, also C++0x anschaut, kann Python noch um einiges komplexer werden ohne C++ ein zu holen.

Mit der C++ Entwicklung hab ich mich sogar beschäftigt, ich halte es für eine der Gründe, warum die Leute wohl eher bei C bleiben werden Ich mag die Programmiersprache aber im Allgemeinen nicht, somit is's wohl nicht gut, dass ich darüber rede. Fänd' es halt nur schade, wenn Python sich sowas als Beispiel nehmen würde... Aber soweit wird es wohl nicht kommen.

@Gerold
Gute Besserung :3 Das hatte ich auch letzte Woche. War grausam!

[gerold]

Gute Besserung

Vielen Dank, euch!

[Costi]

gute besserung auch meinerseits

dekoratoren sind wirklich pracktisch.
da sie informationene beinhalten, die fuer eine methode sehr wichtig sein koennen, sollten sie mit einem blick mit den meth0dennamen und parameter ersichtlich sein

das mit print sehe ich ein.

aber dieses ``a if b else c`` war nicht noetig.
wenn man will kannman das mit ``and``s und ``or``s auch!

und warum brauchen wir vor jeden block diese ``:``.
die eirueckung mach tdoch solcheangaben trivial!

[BlackJack]

Wenn Du die ':' vor den Blöcken loswerden willst, brauchst Du als erstes mal eine Studie, die belegt, dass sie die Lesbarkeit des Quelltextes *nicht* erhöhen. Für ABC, eine der Sprachen von denen sich Guido inspirieren liess, gibt's nämlich eine Studie, die zu dem Ergebnis kommt, dass der Quelltext mit den ':' leichter lesbar ist. Deshalb gibt's die auch in Python.

[EnTeQuAk]

und warum brauchen wir vor jeden block diese ``:``.
die eirueckung mach tdoch solcheangaben trivial!

Klar, recht hast du. Aber unnötig finde ich sie nicht. Gewisse Dinge machen den Quelltext einfach übersichtlicher. Auch, wenn man nicht offensichtlich drauf achtet. Ich muss zwar zugeben, das ich diese Doppelpunkte das ein oder andere mal vergesse, aber letzendlich gehören sie einfach dazu. Immernoch besser, als jedes Statement mit einem Semikolon abzuschließen

Die Dekoratoren finde ich gar nicht so schlimm, obwohl ich zugebe, dass ich deren Syntax schlicht hässlich finde (j2-Syntax wäre besser, aber das ist ja schon entschieden).

Ich stecke ja nicht so tief drinne, aber wie sieht die dann aus? Groß anders, als die bisherige Schreibweise?


MFG EnTeQuAk

[birkenfeld]

Schade, jetzt ist hier schon alles gesagt.

Da bleibt mir nur noch übrig, dir, Gerold, gute Besserung zu wünschen, und dir zu versichern, dass Python 3 kein Stück "schwieriger" wird als Python 2.

Im Gegensatz, wir reißen gerade wieder einiges alte Zeug raus - unbound methods zum Beispiel.

Und in einem Punkt muss ich meinen Vorrednern rechtgeben: Viele neue "komplizierte" Dinge braucht man weder aktiv noch passiv wissen, wenn man sie nicht einsetzt. (Man braucht sie vielleicht, wenn man anderer Leute Code liest, aber da gibts meistens andere Hürden, die größer sind -- fehlende Doku, "Sauklaue" etc.)

[veers]

Das mit dem print gefällt mir. Ich habe mit schon des öfteren darüber genervt das map(print, ..) o.ä. nicht funktioniert. Dekoratoren finde ich hübschen Syntaktischen Zucker für ein nützliches Konstrukt.

Worüber ich mich Frage sind die Abtrakten Basis Klassen - ist das wirklich nötig? Was für Einsteiger sicherlich nicht ganz einfach sein wird ist die String / Byte Sache in Python 3000. So sind ja Dateinamen unter Unix, grundsätzlich einfach Bytes, unter Windows hingegen Unicode Strings. Naja wir werden sehen

[Leonidas]

Zu der Doppelpunkt-Problematik: bin ich der einzige, der nach dem Dekorator einen Doppelpunkt schreibt?

Zur Syntax: J2 findest du in Punkt J2 im Wiki unter PythonDecorators, eine Diskussion gibt es hier.

[birkenfeld]

Zu der Doppelpunkt-Problematik: bin ich der einzige, der nach dem Dekorator einen Doppelpunkt schreibt?

Du wärst zumindest der einzige, bei dem das keinen SyntaxError wirft...

[Leonidas]

Tuts auch nicht, denn nachdem ich das mache fällt mir das daraufhin ins Auge und ich korrigiere das

[BlackJack]

@veers: ``map(print, iterable)`` ist Böse™. Da konstruierst Du entweder eine unnötige Liste (wahrscheinlich `None`\s) bzw. wird in 3.0 `map()` ja einen Generator zurückgeben, d.h. Du musst dann doch wieder eine Schleife schreiben um die `print()`\s ausführen zu lassen.

[birkenfeld]

@BlackJack:

Code: Alles auswählen

def mapM_(f, xs):
    for x in xs:
        f(x)

und schon is besser

[gerold]

Hallo birkenfeld!

Da bleibt mir nur noch übrig, dir, Gerold, gute Besserung zu wünschen

Vielen Dank!

und dir zu versichern, dass Python 3 kein Stück "schwieriger" wird als Python 2.

So etwas will ich hören. Das hat das Potenzial, mich wieder aufzubauen.

lg
Gerold