Das deutsche Python-Forum

Sieht auch nett aus: http://wiki.netbeans.org/Python

Schon jemand Probiert?

jens hat geschrieben:Schon jemand Probiert?

Such mal nach nbpython, sma hat das schon AFAIR öfter erwähnt.

Hat er. Er ist nicht so der Netbeans-Fan und das wirft dann Schatten auf den Python-Support, der eigentlich schon ganz ordentlich ist. Die EA-Version für Netbeans 6.5 kann das Übliche, was Einrücken und Einfärben angeht. Der integrierte Debugger ist hervorzuheben. Nett ist auch, dass unbenutzte Imports gefunden werden und ein paar andere stilistische Probleme hervorgeben werden. Ich vermisse noch Django-Support. Negativ ist IMHO, dass Python 3 nicht unterstützt wird. Auch b""-Strings von 2.6 sind Syntaxfehler. Zumindest das "with" wird akzeptiert.

Stefan

Weiß jemand wie ich bei Scite die Anzahl der Leerzeichen für die Einrückung _dauerhaft_ umstellen kann?

bremer hat geschrieben:Weiß jemand wie ich bei Scite die Anzahl der Leerzeichen für die Einrückung _dauerhaft_ umstellen kann?

[wiki]Scite Integration[/wiki]

Thx, hab's hinzugefügt.

Hallo,
hier wird ein PHP-Editor vorgestellt, dessen Fähigkeit, automatisch Docstrings zu erzeugen, beeindruckt hat. Kann denn irgendeiner der euch bekannten Editoren sowas?
..was ich sonst noch ganz nützlich fände:

* Bei Erstellen einer Klasse gleich das __init__, __str__ erstellen
* Dokumentationsintegration (wenn ich mich mit dem Cursor auf os.path.join(blah, blubb) befinde, soll die Syntax der Funktion plus Erklärung usw zB in der Statusbar dargestellt werden (am besten auch noch für Fremdmodule))

Zur Zeit nutze ich Geany, der *wirklich genial* ist (schnell, Code-Vervollständigung, automatisches Ausführen per Knopfdruck (Terminal!), super Syntax-Highlighting, unterstützt auch andere Sprachen (gut für z.B. Webentwicklung wg. Jinja/HTML/CSS),...).

Dauerbaustelle hat geschrieben:hier wird ein PHP-Editor vorgestellt, dessen Fähigkeit, automatisch Docstrings zu erzeugen, beeindruckt hat. Kann denn irgendeiner der euch bekannten Editoren sowas?
..was ich sonst noch ganz nützlich fände:

* Bei Erstellen einer Klasse gleich das __init__, __str__ erstellen

Also wenn ich Flash hätte, könnte ich dir vielleicht folgen. Habe ich aber nicht und auch nicht die Zeit mir das Ding anzusehen, daher die Frage: wie meinst du das?

Ansonsten kann ich mir mit snippetsEmu durchaus auch Klassen mit ``__init__`` und ``__str__`` generieren lassen. Tue ich aber nicht weil ich die magischen Funktionen nur dann definiere wenn ich sie brauche und nicht einfach so, pauschal.

Leonidas hat geschrieben:daher die Frage: wie meinst du das?

Nunja, mal angenommen ich definiere eine Methode `do_blah`:

Code: Alles auswählen

def do_blah(foo, bar, **blubb):
    pass

und jetzt fange ich an, vor dem `pass` Docstrings zu definieren (ich tippe `"""` ein), der Editor ergänzt diese automatisch:

Code: Alles auswählen

def do_blah(foo, bar, **blubb):
    """
        @param foo:
        @param bar:
        @param blubb:
    """
    pass

weischdu.

Ah, ok. Ne, das kann vim nicht. Das könnte vielleicht Emacs python-mode, wenn man es implementiert.

So etwas würde ich nicht haben wollen. Ähnlich wie Leonidas Argument zu automatischem `__str__()`, gibt's auch viele Funktionen wo eine kurze Beschreibung der Funktion selbst ausreicht und die Argumente durch die Namen schon genau genug beschrieben sind, so dass man sie nicht noch einmal alle explizit einzeln beschreiben muss.

Das führt letztendlich oft zu so toller Dokumentation wie:

Code: Alles auswählen

def do_blah(foo, bar, **blubb):
   """
       @param foo: a foo object.
       @param bar: a bar object.
       @param blubb: some blubbs.
   """
   pass

Das ist IMHO fast schlimmer als gar keine Dokumentation.

Leonidas hat geschrieben:Ah, ok. Ne, das kann vim nicht. Das könnte vielleicht Emacs python-mode, wenn man es implementiert.

Na wenn du sowieso snippetsEmu benutzt, bekommst du das bei `def<tab>' auch spendiert

Sogar `self-aware' (d.h. sself wird nicht in die Argument-Liste aufgenommen

)

Aber BlackJacks Einwand sollte man sich doch zu Herzen nehmen

Wobei das ganz nützlich ist, wenn man API Dokumentation aus dem Code erstellt.

@BlackJack: Wenn ich `"""` unter der Methodendefintion tippe, dann habe ich höchstwahrscheinlich vor, Dokumentation zu schreiben. Und wenn schon Doku, dann auch für alle Paramater.

Dauerbaustelle hat geschrieben:@BlackJack: Wenn ich `"""` unter der Methodendefintion tippe, dann habe ich höchstwahrscheinlich vor, Dokumentation zu schreiben. Und wenn schon Doku, dann auch für alle Paramater.

Nein, wieso?

Code: Alles auswählen

def primes_to(n):
    """Returns all prime numbers from 0 to n"""
    pass

Das Video zeigt Aptanas Eclipse-basierte PHP-IDE. Aus Sicht eines Java-Entwicklers sieht man dort nichts, was gute Java-IDEs nicht schon seit vielen Jahren können und was IMHO eine IDE eigentlich ausmacht: Ein intimes Verständnis der Struktur des Programms und der Typisierung der einzelnen Ausdrücke und darauf basierende Hilfen im Editor.

So etwas ist in einer statisch getypten Sprache wie Java natürlich einfacher als in einer dynamisch getypten wie PHP oder eben auch Python, aber würde man sich etwas mehr Mühe geben, könnte es auch besser sein als die aktuelle Situation, wo man eigentlich kaum mehr hat, als ein Texteditor mit Syntaxhighlighting.

Aptana hat übrigens auch den Entwickler von pydev, einem Python-Plugin für Eclipse, angestellt und bietet auch Python-Support in ihrem Studio-Produkt. Das Ding ist aber primitiver im Vergleich zu dem, was sie da jetzt für PHP demonstrieren. Pydev wäre aber open source und man könnte wahrscheinlich im Eclipse JDT oder PDT nachschauen, wie das automatische Erzeugen der Doc-Kommentare funktioniert und auf die selbe Weise dann in Pydev einen docstring bauen.

Leider ist es in Eclipse sehr aufwendig, einige Plugins für neue Sprachen zu bauen, sodass ein gutes Python-System ein mehrmonatiges Projekt wäre und nicht nur eine interessante Aufgabe für ein Wochenende :( Leider sind daher auch 80% aller Plugins Müll und man muss sich seinen eigenen IDE-Flickenteppich zusammennähen.

Möglicherweise wäre es einfacher, sich wirklich mal in einen der generischen Editoren wie Emacs oder Vim einzuarbeiten. Leider haben beide auf Grund ihres Alters inzwischen eher ungewöhnliche Tastenkombinationen und speziell der Emacs wirkt auf mich in der Grundkonfiguration sehr archaisch.

Stefan

sma hat geschrieben:So etwas ist in einer statisch getypten Sprache wie Java natürlich einfacher als in einer dynamisch getypten wie PHP

PHP ist ja eigentlich gar nicht typsicher

Und zumindest meiner Erfahrung nach ist die Autovervollständigung, die gängige PHP-Plugins für Eclipse bieten, auch nicht besser als die, die Pydev und Eric 4 für Python bieten. Allerdings habe ich auch nur die freien Plugins getestet, Aptana-Studio kenne ich nicht.

Möglicherweise wäre es einfacher, sich wirklich mal in einen der generischen Editoren wie Emacs oder Vim einzuarbeiten. Leider haben beide auf Grund ihres Alters inzwischen eher ungewöhnliche Tastenkombinationen und speziell der Emacs wirkt auf mich in der Grundkonfiguration sehr archaisch.

Du könntest ja auch einfach eine existierende Konfiguration übernehmen. Ich würde dir auch meine Konfiguration geben, aber da ich nicht so wirklich auf IDE-Automatismen stehe, wird sie dir eher nicht helfen.

Zumindest die geforderten Dinge wie automatische Docstring- und Klassen Templates lassen sich mit yasnippet für Emacs umsetzen, und die mittels ElDoc kann man sich im Minibuffer (~ Statuszeile von Emacs) auch die Docstring-Dokumentation zum aktuellen Objekt anzeigen lassen. Wie gut das funktioniert? Keine Ahnung, ich habe es zwar aktiviert, achte da aber nicht allzu groß drauf, da ich die Doku meistens im Browser bzw. in IPython beim Ausprobieren lese.

Leonidas hat geschrieben:
Dauerbaustelle hat geschrieben:@BlackJack: Wenn ich `"""` unter der Methodendefintion tippe, dann habe ich höchstwahrscheinlich vor, Dokumentation zu schreiben. Und wenn schon Doku, dann auch für alle Paramater.
Nein, wieso?
Code: Alles auswählen
def primes_to(n):
    """Returns all prime numbers from 0 to n"""
    pass

Doch, sowas wäre interessant wenn man zb mit doxygen eine dokumentation automatisch erstellen lassen will. Da braucht man zb die @param Symbole

Nein, es braucht diese meist idiotischen Markup-Konstrukte nicht (und nein, auch nicht für Doxygen). Denn wo genau läge denn der Mehrwert an Dokumentation, wenn unter "Returns all primes from 0 to n" noch mal "@param n the number, up to which all primes are returned" stünde? Genau, es gibt keinen Mehrwert. Und daran ändert auch fancy doxygen nichts

Fazit: Wenn der Fließtext alle relevanten Informationen enthält, dann braucht es kein komisches Markup für Dokumentationstool XYZ, das nimmt dann nämlich nur Platz im Browser weg, der besser hätte genutzt werden können. Zumal die aus solchen Platzhaltern resultierende Dokumentation in der Realität nämlich meist exakt so aussagekräftig ist wie die in BlackJacks Beispiel

Im Übrigen ist Doxygen eh ungeeignet für Python, und der Sinn aus Docstrings generierter API-Dokumentation auch eher fraglich. "pydoc -p 9000" birgt nämlich exakt den gleichen Informationswert.

Dann schon lieber Sphinx, wo man geschriebene Dokumentation (die imho sowieso mehr bringt als API-Doc) mit API-Dokumentation kombinieren kann.

burli hat geschrieben:Doch, sowas wäre interessant wenn man zb mit doxygen eine dokumentation automatisch erstellen lassen will. Da braucht man zb die @param Symbole

Doxygen-Dokumentation liest sich jämmerlich, siehe auch z.B. python-openid, das EPyDoc verwendet. Da ist mir eine Sphinx-Dokumentation tausend mal lieber auch wenn nicht jeder Parameter mit so Weisheiten wie "n: a number" dokumentiert ist.

Hm, eigentlich dachte ich, ist dieser Thread nicht zur Grundsatzdiskussion da.

Das deutsche Python-Forum

Editoren für Python