Python source beautifier

[Francesco]

Hallo, ich kann es kaum glauben, aber mit google fand ich keinen (brauchbaren) python code beautifier.

Warum werden sich einige fragen, programmier gleich ordentlich.

Ich habe einige Fremdsourcen, in der z.b. nicht auf spaces 4 programmiert wurde. (Ich kenne reindent.py, such aber eher eine Komplettlösung, schön wäre auch eine Gui).

Hm, wäre eventuell auch ein nettes Projekt, nur ich selber habe keine Zeit momentan.

Features, die ich mir wünschen würde.
Use Spaces, size: 4
macht aus (unnötigen) if (a > b): if a > b
fügt spaces ein (nicht aber bei Funktionen)
a+=1 => a += 1
p(t + 1) => p(t+1)

macht aus konstrukte:
self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1
aus is == und "is not" != (ok das wäre einfach)
break long lines (vernünftig)
macht aus compare if len(string) > 0: => if string:
if if len(string) < 1 oder if string == "" => if not string

detect mixed line ending
detect tabs mixed with space
trim trailing whitespaces.

Gibt es irgendwo so ein Tool?

[EyDu]

aus is == und "is not" != (ok das wäre einfach)

und dämlich noch dazu

[Francesco]

aus is == und "is not" != (ok das wäre einfach)

und dämlich noch dazu

Naja, muss das schon ein bisschen relativieren.
Ich weiss ja nicht (bitte korrigiert mich), hat es nicht früher (irgendwann bei 1.5 oder noch vorher) noch gar nicht den != operator gegeben?

Ausserdem: is not: vielleicht bevorzugt irgendwer diese Schreibweise? *zuck*

[mkesper]

Z.B. PEP 8:

- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.

[Francesco]

Z.B. PEP 8:

- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.

Hm, aber es macht keinen Unterschied, oder?

[EyDu]

Hm, aber es macht keinen Unterschied, oder?

Doch. Stell dir mal vor du hast einen Unit-Test test und möchtest überprüfen, ob dein Singleton wirklich nur einmal konstruiert worden ist. Ein Test über "==" könnte falsche Ergebnise liefern, ein Test über "is" nicht.

Gut zugegeben, dieses Beispiel ist sehr Konstruiert, aber es gibt halt Situationen in denen der Unterschied wichtig ist.

[CM]

Hoi,

möchte auch meinen Senf dazu abgeben:

macht aus (unnötigen) if (a > b): if a > b

Das mag hier unnötig sein, erhöht aber in anderen, ähnlichen Fällen die Lesbarkeit. PEPs hin oder her: Ich mache das sehr häufig und stehe auch dazu. Ein paar zusätzliche Klammern helfen mir - gerade bei verschachtelten Abfragen - den Durchblick zu bewahren, auch wenn die Klammern das Ergebnis nicht ändern würden.

macht aus konstrukte:
self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1

Muß man hierbei nicht überprüfen, ob die Objekte vom selben Typ sind? In den meisten Fällen dürfte das kein Problem sein, aber was, wenn self.scriptcount kein Integer oder Float ist und das '+' "überladen"? Ließen sich solche Fälle für "beautifier" immer eindeutig lösen?

macht aus compare if len(string) > 0: => if string:
if if len(string) < 1 oder if string == "" => if not string

Der Beautifier dürfte an dieser Stelle ein bißchen umständlich werden: Auch hier muß überprüft werden, ob der Typ wirklich einem String entspricht.

Bzgl. Unittest: Sooo konstruiert ist die Sache nicht, etwas in der Richtung ist mir schon passiert

Gruß,
Christian

[EyDu]

macht aus konstrukte:
self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1

Muß man hierbei nicht überprüfen, ob die Objekte vom selben Typ sind? In den meisten Fällen dürfte das kein Problem sein, aber was, wenn self.scriptcount kein Integer oder Float ist und das '+' "überladen"? Ließen sich solche Fälle für "beautifier" immer eindeutig lösen?

Auch das funktioniert nicht, da die Semantik von + und += verschieden sind. Bei + erwartet man ein neues Objekt, bei += eine Veränderung die in-place geschieht (wenn möglich). An Listen wird das Problem schon deutlich. Noch besser wird es dann, wenn + und += noch völlig verschieden überladen werden, weil jemand dies aus irgend einem Grund für sinnvoll hält.

(IDLE)

Code: Alles auswählen

>>> a=[1]
>>> b=[2]
>>> c=a+b
>>> c
[1, 2]
>>> a
[1]
>>> b
[2]
>>> a+=b
>>> a
[1, 2]

[Leonidas]

Z.B. PEP 8:

- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.

Hm, aber es macht keinen Unterschied, oder?

Doch. ``is`` und ``is not`` testen auf Identität, ``==``, ``!=`` und ``<>`` auf Gleichheit. Und das muss nicht immer das gleiche sein, so können zwei verschiedene Objekte gleich sein, aber nicht die gleiche Identität haben.

@EyDu: Irgendwie entgeht mir der Sinn deines Codebeispiels. Wenn man statt ``c = a + b`` ``a = a + b`` kommt man genau auf das gleiche Ergebnis. Und wirklich überraschend ist es ja nicht, da das ``+=`` ja irgendwie klar macht, dass die Variable *) links davon geändert wird.

*) oder genauer das an den Namen gebundene Objekt

[CM]

@EyDu: Eben, genau das ist das Argument. Allerdings verstehe ich ebensowenig wie Leonidas, was Du mit dem Beispiel eigentlich zeigen willst - aus dem gleichen Grund wie Leonidas.

[rayo]

Hi

Ich denke das Beispiel sollte eher so sein:

Code: Alles auswählen

a = [1]
b = [2]
c = a
a = a+b
print 'a:',a
print 'c:',c

a = [1]
b = [2]
c = a
a += b
print 'a:',a
print 'c:',c

Ausgabe:

Code: Alles auswählen

a: [1, 2]
c: [1]

a: [1, 2]
c: [1, 2]

Kommt also nicht aufs gleiche.

Gruss

[EyDu]

rayo hat da schon ganz richtig vermutet, was ich meinte. Nächstes mal lese ich einfach noch mal durch was ich poste

[Joghurt]

Wie schon geschrieben machen "is" und "==" etwas anderes: Ein schönes Beispiel:

Code: Alles auswählen

>>> a = 50
>>> b = 50
>>> a is b
True
>>> a = 100
>>> b = 100
>>> a is b
False

(hier CPython, in Jython kann das noch ganz anders aussehen)

Warum ist das so? Wenn du "50" schreibst, wird ein Integer-Objekt mit dem Wert 50 erzeugt, dito für "101", jedoch ist bei CPython eine kleine Optimierung vorgenommen worden, so werden alle Integers von 0 bis 99 einmal global erzeugt und gecacht, so dass sie, wenn man wieder ein Integer mit dem Wert "42" gebraucht wird, auf die bereits existierende Instanz verwiesen werden kann. Bei Zahlen über 99 wird das Objekt jedesmal neu erzeugt; und is schaut nunmal, ob es sich um dasselbe Objekt handelt, ==, ob es sich um ein gleiches Objekt handelt.

[dst]

Ist das letzte Beispiel nicht eher ein Grund dafür, in den meisten Fällen == zu benutzen?
Gerade bei primitiven kommt es doch i.d.R. weniger auf Identität als auf Wertigkeit an.

[CM]

Das ist der entscheidende Punkt:

i.d.R.

Also kann ein potentieller beautifier '==' und 'is' nicht gleichsetzten. Was im Programm relevant ist, ist natürlich eine ganz andere Frage.

[Francesco]

Wie schon geschrieben machen "is" und "==" etwas anderes: Ein schönes Beispiel:

Code: Alles auswählen

>>> a = 50
>>> b = 50
>>> a is b
True
>>> a = 100
>>> b = 100
>>> a is b
False

(hier CPython, in Jython kann das noch ganz anders aussehen)

Würg, das ist ein Hammer.
Wie soll man auf so etwas kommen, ohne sich genau zu informieren?
Intuitiv ist das nicht gerade.

[Leonidas]

Wie soll man auf so etwas kommen, ohne sich genau zu informieren?
Intuitiv ist das nicht gerade.

Darauf kommt man nicht. Wer testet schon ob eine Instanz der Int-Klasse gleich einer anderen (oder eben der gleichen) Instanz der Int-Klasse ist. Dafür gibt es ``==`` und sonst gibt es mit dieser Optimierung in echten Programmen keinerlei Probleme.

[EyDu]

Wie soll man auf so etwas kommen, ohne sich genau zu informieren?

Ich werde ja das Gefühl nicht los, dass einige Menschen versuchen Programiersprachen nur durch ausprobieren zu lernen und mit wenig Untersütztung von Literatur ... Aber wenn man mit solchen Feinheiten nicht in Kontakt kommt ist das ja auch in Ordnung. Immerhin braucht eine Sprache ja auch eine breite Basis.

Intuitiv ist das nicht gerade.

Wenn man den Unterschied von Objektgleichheit und Wertegleichheit kennt schon

[BlackJack]

Dem würde ich mich anschliessen. Das ``=`` eine Zuweisung und ``==`` ein Vergleich ist, ist auch nicht intuitiv. Oder ``lambda``. Closures. Klassen. Metaklassen. Sichtbarkeitsbereiche von Namen. Man muss halt Doku lesen wenn man wissen will was für eine Semantik hinter den Syntaxkonstrukten steckt.

[Mad-Marty]

weitere anmerkung zu == & is:

Code: Alles auswählen

>>> True is 1
False
>>> True == 1
True