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?
Python source beautifier
Naja, muss das schon ein bisschen relativieren.EyDu hat geschrieben:und dämlich noch dazuFrancesco hat geschrieben: aus is == und "is not" != (ok das wäre einfach)
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*
Hm, aber es macht keinen Unterschied, oder?mkallas hat geschrieben:Z.B. PEP 8:- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.
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.Francesco hat geschrieben:Hm, aber es macht keinen Unterschied, oder?
Gut zugegeben, dieses Beispiel ist sehr Konstruiert, aber es gibt halt Situationen in denen der Unterschied wichtig ist.
Hoi,
möchte auch meinen Senf dazu abgeben:
Bzgl. Unittest: Sooo konstruiert ist die Sache nicht, etwas in der Richtung ist mir schon passiert
Gruß,
Christian
möchte auch meinen Senf dazu abgeben:
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.Francesco hat geschrieben: macht aus (unnötigen) if (a > b): if a > b
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?Francesco hat geschrieben: macht aus konstrukte:
self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1
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.Francesco hat geschrieben: macht aus compare if len(string) > 0: => if string:
if if len(string) < 1 oder if string == "" => if not string
Bzgl. Unittest: Sooo konstruiert ist die Sache nicht, etwas in der Richtung ist mir schon passiert
Gruß,
Christian
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.CM hat geschrieben: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?Francesco hat geschrieben: macht aus konstrukte:
self.scriptcount = self.scriptcount + 1 => self.scriptcount += 1
(IDLE)
Code: Alles auswählen
>>> a=[1]
>>> b=[2]
>>> c=a+b
>>> c
[1, 2]
>>> a
[1]
>>> b
[2]
>>> a+=b
>>> a
[1, 2]
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Francesco hat geschrieben:Hm, aber es macht keinen Unterschied, oder?mkallas hat geschrieben:Z.B. PEP 8:- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.
@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
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@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.
-
- User
- Beiträge: 773
- Registriert: Mittwoch 5. November 2003, 18:06
- Wohnort: Schweiz
- Kontaktdaten:
Hi
Ich denke das Beispiel sollte eher so sein:
Ausgabe:
Kommt also nicht aufs gleiche.
Gruss
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
Code: Alles auswählen
a: [1, 2]
c: [1]
a: [1, 2]
c: [1, 2]
Gruss
Wie schon geschrieben machen "is" und "==" etwas anderes: Ein schönes Beispiel:(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.
Code: Alles auswählen
>>> a = 50
>>> b = 50
>>> a is b
True
>>> a = 100
>>> b = 100
>>> a is b
False
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.
Das ist der entscheidende Punkt:
Also kann ein potentieller beautifier '==' und 'is' nicht gleichsetzten. Was im Programm relevant ist, ist natürlich eine ganz andere Frage.dst hat geschrieben: i.d.R.
Würg, das ist ein Hammer.Joghurt hat geschrieben:Wie schon geschrieben machen "is" und "==" etwas anderes: Ein schönes Beispiel:(hier CPython, in Jython kann das noch ganz anders aussehen)Code: Alles auswählen
>>> a = 50 >>> b = 50 >>> a is b True >>> a = 100 >>> b = 100 >>> a is b False
Wie soll man auf so etwas kommen, ohne sich genau zu informieren?
Intuitiv ist das nicht gerade.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Francesco hat geschrieben:Wie soll man auf so etwas kommen, ohne sich genau zu informieren?
Intuitiv ist das nicht gerade.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.Francesco hat geschrieben: Wie soll man auf so etwas kommen, ohne sich genau zu informieren?
Wenn man den Unterschied von Objektgleichheit und Wertegleichheit kennt schonFrancesco hat geschrieben: Intuitiv ist das nicht gerade.
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.
weitere anmerkung zu == & is:
Code: Alles auswählen
>>> True is 1
False
>>> True == 1
True