Das deutsche Python-Forum

Hiho.
Hier in dem Forum wird ja immer wieder Code (vorallem von Anfängern) bemängelt, weil er nicht nach diesem Style-Guide programmiert wurde.
Zum Beispiel, wie man Methodennamen schreiben sollte (unterstriche oder nicht, usw), dass man keine *-Importe machen sollte usw.
80 Zeichen (das hat der Standardeditor ja schon als Fenstergröße drin) pro Zeile, wie man Kommentare schreiben sollte, ...
Ihr kennt's ja
Außerdem werden auch so Sachen bemängelt, dass man kein ``range()`` in ``for`` Schleifen benutzen sollte, sondern ``xrange()``.
Oder dass Funktionen in der nächsten Pythonversion nicht mehr zur verfügung stehen werden und man daher auf sie verzichten sollte.
Es gibt ja genug Kleinigkeiten, die immer wieder kritisiert werden.
Aber die meisten dieser Sachen könnte ja auch ein Editor erkennen.
Gibt es vielleicht schon einen Editor der solche Dinge erkennt und einen darauf hinweist?
Wenn nicht, wäre das doch ein tolles Projekt für die engagierten Leute hier im Board
Würde ja auch reichen, wenn man den Standardeditor für Python erweitern würde.
Ich stell mir das so vor:
Man benutzt in einer ``for`` Schleife ``range()`` und dann markiert der Editor das und wenn man die Maus draufhält, wird angezeigt, was dagegen einzuwenden ist (Eventuell ein Auszug aus dem Style-Guide) und eine Alternative vorgeschlagen. Wenn der Programmierer aber meint, dass in diesem Falle ``range()`` durchaus berechtigt ist (was ja eventuell auch mal sein kann), dann kann man auch einfach auf "ignorieren" oder so klicken und dann verschwindet der Hinweis und die Markierung.

Einige werden es vielleicht sinnlos finden oder es für den Aufwand nicht wert halten.
Aber ich denke schon, dass das etwas sinnvolles wäre.
Readability counts, oder? Und das wäre doch schonmal ein Schritt in die richtige Richtung Dann könnte man sich als Python Anfänger bequem aneignen, "richtig" zu programmieren, ohne sich alle möglichen Texte durchlesen zu müssen. Dazu haben sicherlich die wenigsten lust.
Leute die vorher schon seit 10 Jahren programmiert haben, werden kein Problem damit haben sich mal eben daran zu gewöhnen und auch mal ein paar Texte durchzulesen, aber für Anfänger ist's ja schon genug Arbeit, erstmal das programmieren zu lernen und _überhaupt_ Code zu fabrizieren, der funktioniert. Und wenn man sich dann noch nach dem Style-Guide richten soll und dies und jenes noch beachten muss, dann wird's auch irgendwann zu viel
Und ich persönlich fänd's auch richtig gut, weil ich mir eh nie merken kann, ob ich jetzt Unterstriche in die Namen schreiben soll, oder doch nicht, usw.
Was haltet ihr davon? Oder, wie schon oben gefragt, gibt's sowas in der Art schon? Kann ja auch sein :p

Was du beschreibst ist etwas, das bei IDEs für Java Standard ist. Auch Suns Netbeans-basierte Ruby/Rails-IDE kann mit Prüfungen zu coding conventions, deprecation, best practices etc. aufwarten. Ich hielte es daher auch für eine gute Idee für Python.

Ich hatte so ein bisschen die Hoffnung, dass Sun für Python ähnliches für Netbeans auf die Beine stellen kann, bin aber inzwischen skeptischer, weil sie wohl nur den Bau einer IDE koordinieren werden. Nichts desto trotz kann man sich dort bestimmt einbringen. Eine andere Alternative scheint mir das Eclipse-basierte pydev zu sein, allerdings will deren Autor ja mit den pydev extensions sein Geld verdienen und die Features klingen, als ob sie dort besser passen.

In jedem Fall bräuchte man IMHO eine IDE-Infrastruktur, in der man die Programmstruktur in Form eines AST zur Verfügung hat und idealerweise auch Typinferenz um dann die notwendigen Analysen zu programmieren. Am übersichtlichsten fand ich übrigens bei Intellij IDEA (im Gegensatz zu den anderen beiden Java-basierten IDEs nicht opensource) neue Analysen (für Java allerdings) einzubauen. Für diese IDE, die zwar auch Ruby, Groovy und andere Scriptsprachen unterstützt, gibt es leider bislang keinen nennenswerten Python-Support.

Direkt für Python gibt es wohl bei SPE und Eric bemühungen, tools wie pylint oder pychecker einzubinden, das ganze wirkt aber auch mich weniger integriert als ich mir das vorstelle und speziell pychecker scheint irgendwann man nicht weiter entwickelt worden zu sein.

Stefan

`pydev` kann `pylint` benutzen und die Informationen direkt im Editor an zeigen.

Da sehr viele Python-Programmierer aber anscheinend lieber einen einfachen Editor statt einer IDE verwenden, würde ich eher auf einzelne Werkzeuge wie `pylint` oder `pychecker` setzen, und nicht auf so eine IDE warten.

Also ich bin keiner dieser Entwickler, die mit Wasser und Brot zufrieden sind und hätte gerne eine gute IDE. Daher sehe ich nicht, wieso "man" oder "ich" jetzt auf Einzeltools setzen sollte, weil die anderen nicht so denken ;)

Stefan

Wasser und Brot? Nö, ich seh's eher als Champagner und Kaviar. Nur eben *einzeln* statt als Brei vermischt, und ich kann mir die Marken selber aussuchen.

Naja, sowas sollte zu einen recht großen Teil mit vims und emacs Skriptsprache zu machen sein, sie können wohl beide irgendwie underline darstellen, jetzt noch reguläre Ausdrücke hereinmischen und fertig.

Allerdings sind in der Regel Nutzer dieser Editoren sich des guten Stils in Python bewusst bzw. auch bereit Pylint etc. extern zu nutzen, so dass eine Integration in Emacs oder vim nicht wirklcih auch die Zielgruppe trifft.

Vielleicht sollte man so etwas als DrPython-Plugin. Man kann man das ja Francesco vorschlagen.

(sry erstmal, schreib grade mit Window's Desktoptastatur = per Maus)
Ich werf jetzt nur kurz noch eine weitere Idee ein:
Man kann das ganze doch auch als Pythonskript im Hintergrund laufen lassen, welches sich den Text aus _jedem_ Editor holen kann und somit völlig unabhängig ist, oder? Möglich dass es sich mit dem Markieren der Stellen usw dann schwer gestaltet aber dafür könnte man auch ein eigenes Fenster benutzen: Analyse Text -> Neues Fenster mit Sourcecode öffnet sich, in dem die Stellen markiert sind usw.

Da sehe ich nicht den Vorteil gegenüber manuellem Aufrufen. Klar das sowas möglich ist, aber ohne Editor-Integration in dem man das sofort ändern kann, ist das ganze ziemlich witzlos.

Leonidas hat geschrieben:Da sehe ich nicht den Vorteil gegenüber manuellem Aufrufen. Klar das sowas möglich ist, aber ohne Editor-Integration in dem man das sofort ändern kann, ist das ganze ziemlich witzlos.

Ich weiß ja nicht wie viel man so ohne weiteres mit einem im hintergrundlaufendem Programm möglichst editorunabhängig machen kann. Aber allein wenn man was für IDLE und 2-3 andere oft benutzte Editoren entwickeln würde, reicht das ja erstmal. Aber das gibt's ja anscheinend schon für manche Editoren, ich denke ich schau mir das mal an, dann weiß ich auch besser bescheid

Das Programm wird wohl nicht Editorabhängig sein, man könnte aber sicher eine Emacs-Erweiterung schreiben, die beim Speichern pylint startet und dann den Code checken lässt und dessen Warnungen am Code anträgt. In DrPython könnte es sogar mit noch direkterer Integration klappen, ohne das da Prozesse gestartet werden müssen.

Diese "Erweiterung" sieht im einfachsten Fall so aus: Ist noch etwas roh (man müsste im Hook den major-mode checken), hat aber schon hohes "Nerv"-Potential

lunar hat geschrieben:Diese "Erweiterung" sieht im einfachsten Fall so aus:

Code: Alles auswählen

(load-library "pylint")
(add-hook 'python-mode-hook '(lambda () (add-hook 'after-save-hook 'pylint)))

Ist noch etwas roh (man müsste im Hook den major-mode checken), hat aber schon hohes "Nerv"-Potential

sollte genügen.

Darf man fragen über was ihr redet?

Karl hat geschrieben:Darf man fragen über was ihr redet?

Es geht darum, wie man Pylint in Emacs am besten einbindet.

Ich habe hier noch einen Artikel, der interessant sein könnte: Humane Code Highlighting. Sowas könnte man sicherlich auch in den Python-Mode implementieren.

Also ich bin mit Eclipse + PyDev eigentlich ganz zufrieden. Wenn man PyLint aktiviert, sieht man Hinweiszeichen direkt links neben der Codezeile. Man kann mit der Maus über das Hinweiszeichen fahren und sieht info's dazu.

Screenshot, wie das ganze aussieht gibt es unter http://pydev.sourceforge.net/pylint.html (Ist allerdings kein Bild von dem geschilderten Fall dabei)

(So, jetzt nochmal im richtigen Thread... )

Mir persoenlich reicht es, pylint aus Emacs heraus manuell aufzurufen. Emacs oeffnet dann ein zweites Fenster mit der Ausgabe von pylint, man kann auf die Fehlermeldungen/Warnungen klicken und kommt dann an die entsprechende Zeile im Sourcecode.

Diejenigen, denen das nicht reicht, koennen pylint mit Emacs' flymake kombinieren: http://blog.printf.net/articles/tag/emacs

Rebecca hat geschrieben:Mir persoenlich reicht es, pylint aus Emacs heraus manuell aufzurufen. Emacs oeffnet dann ein zweites Fenster mit der Ausgabe von pylint, man kann auf die Fehlermeldungen/Warnungen klicken und kommt dann an die entsprechende Zeile im Sourcecode.

Klar, wer will auch schon jedes Mal beim Speicher gezeigt bekommen, wie scheiße der eigene Code ist ... das deprimiert doch total.

Also ich komme regelmäßig auf >9/10.

Natürlich mit meiner eigenen pylint-Konfigurationsdatei.

birkenfeld hat geschrieben:Also ich komme regelmäßig auf >9/10.

Ich auch: ``pylint --evaluation 10 foo.py``

Ich komme immer auf 11/10, sogar ohne Pylint, da ich weiß dass mein Code sowieso immer optimal ist, was auch sonst