string zu no string konvertieren ?
Also ich persönlich würde noch eine Klasse für eine Seite eines Würfels springen lassen. Die gibt IMHO genug Daten und Operationen her, um eine eigene Klasse zu rechtfertigen.
Und die GUI kann man sicher auch auf mehrere Klassen aufteilen, also zum Beispiel mindestens ein Widget als "View" (und vielleicht auch "Controller") aus MVC für den Würfel, dass dann in die Anwendung eingebaut werden kann.
Für die ``for``-Frage: Schau Dir mal die Funktionen `zip()`, `itertools.izip()`, und `enumerate()` an.
Und die GUI kann man sicher auch auf mehrere Klassen aufteilen, also zum Beispiel mindestens ein Widget als "View" (und vielleicht auch "Controller") aus MVC für den Würfel, dass dann in die Anwendung eingebaut werden kann.
Für die ``for``-Frage: Schau Dir mal die Funktionen `zip()`, `itertools.izip()`, und `enumerate()` an.
-
- User
- Beiträge: 38
- Registriert: Samstag 24. November 2007, 16:50
Hatte mir eingebildet das die zip-Funktion keine dictionarys zusammenfassen kann. Funktioniert allerdings einfandfrei , danke.
Jetzt ist allerdings ein neues Problem aufgetaucht:
Ich erstelle, mit einer Klasse, ein Fenster und mainloope es. Normalerweise konnte ich, nachdem ich diesen mainloop ausgefuehrt hatte, weiterhin die Oberflaeche, ich diesem Fall eine canvas Oberflaeche veraendern und um es erscheinen zu lassen, updaten:
Jetzt kommt allerdings folgende Fahlermeldung:
Traceback (most recent call last):
File "C:\Dokumente und Einstellungen\workspace\Training - Python\src\uebung.py", line 157, in <module>
Root().placing_fields()
File "C:\Dokumente und Einstellungen\workspace\Training - Python\src\uebung.py", line 154, in placing_fields
self.canvas.create_rectangle(position[0][0],position[0][1],position[0][2],position[0][3],fill=position[1])
File "C:\Python25\lib\lib-tk\Tkinter.py", line 2166, in create_rectangle
return self._create('rectangle', args, kw)
File "C:\Python25\lib\lib-tk\Tkinter.py", line 2145, in _create
*(args + self._options(cnf, kw))))
_tkinter.TclError: invalid command name ".12420240"
Das Fenster oeffnet sich wie gewohnt, wenn ich den mainloop aus Zeile 22 loesche und ihn statt dem update in Zeile 28 aufrufe. Doch dann ist das Programm logischerweise unbrauchbar.
Jetzt ist allerdings ein neues Problem aufgetaucht:
Ich erstelle, mit einer Klasse, ein Fenster und mainloope es. Normalerweise konnte ich, nachdem ich diesen mainloop ausgefuehrt hatte, weiterhin die Oberflaeche, ich diesem Fall eine canvas Oberflaeche veraendern und um es erscheinen zu lassen, updaten:
Code: Alles auswählen
class Root(object):
def __init__(self):
self.fieldlist = {'bottom': ((206, 81, 223, 98), (226, 81, 243, 98), (246, 81, 263, 98),
(206, 101, 223, 118), (226, 101, 243, 118), (246, 101, 263, 118),
(206, 121, 223, 138), (226, 121, 243, 138), (246, 121, 263, 138)),
'front': ((326, 141, 343, 158), (346, 141, 363, 158), (366, 141, 383, 158),
(326, 161, 343, 178), (346, 161, 363, 178), (366, 161, 383, 178),
(326, 181, 343, 198), (346, 181, 363, 198), (366, 181, 383, 198))}
self.root = Tk()
self.root.title("Ein Rubik Cube Programm")
self.bgcanvas = Canvas(self.root, width=710, height=400, bg='#2ff2ff2ff').pack()
self.canvas = Canvas(self.root, width=650, height=220, bg='grey')
self.canvas.place(x=30,y=30)
self.root.mainloop()
def placing_fields(self,colorlist=Cube().main()):
for seite in self.fieldlist:
for position in zip(self.fieldlist[seite],colorlist[seite]):
self.canvas.create_rectangle(position[0][0],position[0][1],position[0][2],position[0][3],fill=position[1])
self.root.update()
Root().placing_fields()
Traceback (most recent call last):
File "C:\Dokumente und Einstellungen\workspace\Training - Python\src\uebung.py", line 157, in <module>
Root().placing_fields()
File "C:\Dokumente und Einstellungen\workspace\Training - Python\src\uebung.py", line 154, in placing_fields
self.canvas.create_rectangle(position[0][0],position[0][1],position[0][2],position[0][3],fill=position[1])
File "C:\Python25\lib\lib-tk\Tkinter.py", line 2166, in create_rectangle
return self._create('rectangle', args, kw)
File "C:\Python25\lib\lib-tk\Tkinter.py", line 2145, in _create
*(args + self._options(cnf, kw))))
_tkinter.TclError: invalid command name ".12420240"
Das Fenster oeffnet sich wie gewohnt, wenn ich den mainloop aus Zeile 22 loesche und ihn statt dem update in Zeile 28 aufrufe. Doch dann ist das Programm logischerweise unbrauchbar.
Du hast noch Schwierigkeiten im Verständnis der OOP.
Statt mit Instanzen zu operieren, operierst du mit Klassen. Eine Klasse ist im Prinzip aber nichts anderes als ein Bauplan für eine Instanz.
Also erzeugst du erst eine Instanz von diesem Bauplan und arbeitest dann mit dieser Instanz.
Also nicht "Root().machwas", sondern z.B. :
Und: Es ist immer hilfreich, wenn du alles an Code postest, was man zum Testen braucht. Die Klasse Cube fehlt aber.
Und: Du solltest dir angewöhnen, Tkinter nicht über *-Import einzubinden. Beliebt ist:
Und: Vergiss, dass es den place()-Geometriemanager gibt.
Statt mit Instanzen zu operieren, operierst du mit Klassen. Eine Klasse ist im Prinzip aber nichts anderes als ein Bauplan für eine Instanz.
Also erzeugst du erst eine Instanz von diesem Bauplan und arbeitest dann mit dieser Instanz.
Also nicht "Root().machwas", sondern z.B. :
Code: Alles auswählen
app = Application()
app.machwas()
Und: Du solltest dir angewöhnen, Tkinter nicht über *-Import einzubinden. Beliebt ist:
Code: Alles auswählen
import Tkinter as tk
root = tk.Tk()
label = tk.Label(root,text="Ich bin ein Label")
label.pack()
root.mainloop()
-
- User
- Beiträge: 38
- Registriert: Samstag 24. November 2007, 16:50
Hm, und wie soll das ohne place() funktionieren ?
Codeteil ist da:
http://paste.pocoo.org/show/90990/
Wie man sieht verwend ich die place Funktion reichlich oft ^^.
Stattdessen grind verwenden oder wie war das gemeint ? Weil pack reicht ja nicht aus um mehrerer Buttons zu plazieren.
Zum Code ist noch zu sagen, dass die Fehlermeldung erst beim schliessen des Tk-Fensters kommt.
Wenn man die mainloop-Anweisung statt der update-Anweisung hinschreib, erscheint, beim Ausfuehren des Programmes, das Tk-Fenster, welches eigenltich erscheinen sollte.
und das importieren von Tkinter als tk hat den Sinn das sich Namensraeume nicht ueberschneiden ?
Codeteil ist da:
http://paste.pocoo.org/show/90990/
Wie man sieht verwend ich die place Funktion reichlich oft ^^.
Stattdessen grind verwenden oder wie war das gemeint ? Weil pack reicht ja nicht aus um mehrerer Buttons zu plazieren.
Zum Code ist noch zu sagen, dass die Fehlermeldung erst beim schliessen des Tk-Fensters kommt.
Wenn man die mainloop-Anweisung statt der update-Anweisung hinschreib, erscheint, beim Ausfuehren des Programmes, das Tk-Fenster, welches eigenltich erscheinen sollte.
und das importieren von Tkinter als tk hat den Sinn das sich Namensraeume nicht ueberschneiden ?
Doch sicher, pack() reicht aus.smashed to pieces hat geschrieben:Hm, und wie soll das ohne place() funktionieren ?
Codeteil ist da:
http://paste.pocoo.org/show/90990/
Wie man sieht verwend ich die place Funktion reichlich oft ^^.
Stattdessen grind verwenden oder wie war das gemeint ? Weil pack reicht ja nicht aus um mehrerer Buttons zu plazieren.
Ja.smashed to pieces hat geschrieben:und das importieren von Tkinter als tk hat den Sinn das sich Namensraeume nicht ueberschneiden ?
Ich verstehe dein vorrangiges Ziel "Hauptsache es läuft", aber das ist kein guter Weg. Setz dich zunächst mal noch weiter mit Tkinter auseinander, bis du die Zusammenhänge und auch die Grundlagen der OOP verstanden hast. Dann kannst du deine jetzigen Probleme selbst lösen.
Zur Lektüre empfohlen: http://www.ferg.org/thinking_in_tkinter ... grams.html
@smashed to pieces: Wenn Du die `mainloop()` aufrufst, dann war's das. Da übernimmt Tk dann das Ruder und Du kannst nur noch auf Rückrufe aus der GUI reagieren, die Du vorher "verdrahtet" hast. Das Konzept nennt sich "ereignisbasierte Programmierung".
Noch eine Ergänzung zum place()-Geometriemanager: Damit ist dein Layout völlig unflexibel.
Keine Ahnung wie es bei dir aussieht, aber vermutlich nicht so wie auf meinem System (hoffentlich!):
Mit pack() wäre das nicht passiert ...
Keine Ahnung wie es bei dir aussieht, aber vermutlich nicht so wie auf meinem System (hoffentlich!):
Mit pack() wäre das nicht passiert ...
Hallo smashed to pieces
Hier ist noch die Variante mit dem Pack-Manager, wie es 'numerix' vorschlägt. Dabei kannst du so richtig verschwenderisch mit dem Tk-Widget 'Frame' umgehen. Mit den Pack-Optionen 'side', 'fill', 'expand', 'padx', 'pady' kannst du dann deiner kreativen Begabung freien Lauf lassen
[Code ausgelagert]
Gruss wuf
Hier ist noch die Variante mit dem Pack-Manager, wie es 'numerix' vorschlägt. Dabei kannst du so richtig verschwenderisch mit dem Tk-Widget 'Frame' umgehen. Mit den Pack-Optionen 'side', 'fill', 'expand', 'padx', 'pady' kannst du dann deiner kreativen Begabung freien Lauf lassen
[Code ausgelagert]
Gruss wuf
Zuletzt geändert von wuf am Donnerstag 13. November 2008, 10:10, insgesamt 1-mal geändert.
Take it easy Mates!
-
- User
- Beiträge: 38
- Registriert: Samstag 24. November 2007, 16:50
Ok danke. Also ersteinmal auf place umruesten.
Da funktioniert es doch auch so, dass erst ein mainloop erfolgt und spaeter mithilfer der update funktion das Fenster erneuert wird !?
http://paste.pocoo.org/show/91022/
Das mit dem mainloopen versteh ich jetzt allerdings nicht mehr. Weil ich brauch doch eine mainloop Anwendung damit sich das Fenster erst einmal oeffnet/zeigt. Wenn man dann nicht mehr das Ausstehn aendern kann ist das doch irgendwie falsch, da sich andauernt graphische Oberflaechen bei Programmen veraendern.@smashed to pieces: Wenn Du die `mainloop()` aufrufst, dann war's das. Da übernimmt Tk dann das Ruder und Du kannst nur noch auf Rückrufe aus der GUI reagieren, die Du vorher "verdrahtet" hast. Das Konzept nennt sich "ereignisbasierte Programmierung".
Da funktioniert es doch auch so, dass erst ein mainloop erfolgt und spaeter mithilfer der update funktion das Fenster erneuert wird !?
http://paste.pocoo.org/show/91022/
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Die Oberflächen verändern sich bei bestimmten Aktionen/Events. Wenn diese Events ausgelöst werden, dann wird in der Regel der Event-Callback aufgerufen, der dann irgendwelche Aktionen ausführt.smashed to pieces hat geschrieben:Das mit dem mainloopen versteh ich jetzt allerdings nicht mehr. Weil ich brauch doch eine mainloop Anwendung damit sich das Fenster erst einmal oeffnet/zeigt. Wenn man dann nicht mehr das Ausstehn aendern kann ist das doch irgendwie falsch, da sich andauernt graphische Oberflaechen bei Programmen veraendern.
Also angenommen du hast einen Button. Dann bindest du eine Funktion an den Button die dann ausgeführt wird, wenn jemand diesen Button klickt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich wiederhole meinen Lektüre-Tipp von oben. Nimm dir mal 1-2 Tage Zeit dafür, gib die Beispiele ein, experimentiere damit. Das Layout dieser Anleitung ist zwar übel, aber wenn man es ausdruckt, geht es.smashed to pieces hat geschrieben:Das mit dem mainloopen versteh ich jetzt allerdings nicht mehr. Weil ich brauch doch eine mainloop Anwendung damit sich das Fenster erst einmal oeffnet/zeigt. Wenn man dann nicht mehr das Ausstehn aendern kann ist das doch irgendwie falsch, da sich andauernt graphische Oberflaechen bei Programmen veraendern.
Das wird dir manche Erleuchtung bescheren.
-
- User
- Beiträge: 38
- Registriert: Samstag 24. November 2007, 16:50
Danke, konnte mein Problem zwar schon loesen, werde mir die Lektuere aber mal genauer anschaun.
Wollt jetzt nur noch einmal fragen, in wie fern es schlecht es ist, global zu verwendet? Also in meinem jetzigem Code wuerde ich beispielsweise das Woerterbuch zum globalen Namensraum hinzufuegen, welches angibt welche Farbe ein bestimmter 'Stein' momentan hat.
Ist es in so einem Fall gerechtfertigt global zu benuetzen oder sollte man die Verwendung allgemein vermeiden, und wenn ja warum?
Wollt jetzt nur noch einmal fragen, in wie fern es schlecht es ist, global zu verwendet? Also in meinem jetzigem Code wuerde ich beispielsweise das Woerterbuch zum globalen Namensraum hinzufuegen, welches angibt welche Farbe ein bestimmter 'Stein' momentan hat.
Ist es in so einem Fall gerechtfertigt global zu benuetzen oder sollte man die Verwendung allgemein vermeiden, und wenn ja warum?
Das Problem mit "global" ist, dass es bereits bei nicht mehr ganz kleinen Programmen schnell unübersichtlich wird, und sich die Gefahr unerwünschter Seiteneffekte erhöht.
In den meisten Fällen lässt sich "global" dadurch vermeiden, dass man über Parameter und Rückgabewerte Daten austauscht. In den seltenen Fällen, wo mir das zu umständlich erscheint, würde ich "global" nur bei ganz kleinen Programmen einsetzen (etwa so viele Zeilen, wie mein Bildschirm ohne zu scrollen anzeigen kann), bei denen sich m.E. eine OOP-Konstruktion nicht lohnt.
Wenn du mit Klassen und Objekten arbeitest, ist "global" überflüssig, weil du das gleiche über Datenattribute von Objekten erreichen kannst.
In den meisten Fällen lässt sich "global" dadurch vermeiden, dass man über Parameter und Rückgabewerte Daten austauscht. In den seltenen Fällen, wo mir das zu umständlich erscheint, würde ich "global" nur bei ganz kleinen Programmen einsetzen (etwa so viele Zeilen, wie mein Bildschirm ohne zu scrollen anzeigen kann), bei denen sich m.E. eine OOP-Konstruktion nicht lohnt.
Wenn du mit Klassen und Objekten arbeitest, ist "global" überflüssig, weil du das gleiche über Datenattribute von Objekten erreichen kannst.
Lesend kannst du ohne global drauf zugreifen. Schreibend nur mit global.
Für "Read Only" Konstanten ist der Modul Namespace da, sofern die Konstante nicht direkt mit einer Klasse verbunden werden könnte.
global braucht man in der Regel nicht. GIbt eigentlich nur selten solche Fälle, maximal vielleicht bei notwendiger Verkapselung von Daten in einem Modul, die mittels einer Setter Funktion gesetzt werden sollen. Bevor man sowas macht sollte man sein Design nochmal überdenken. Wenn du es mehr als maximal einmal verwendest, hast du eigentlich immer ein kränkelndes Design.
Für "Read Only" Konstanten ist der Modul Namespace da, sofern die Konstante nicht direkt mit einer Klasse verbunden werden könnte.
global braucht man in der Regel nicht. GIbt eigentlich nur selten solche Fälle, maximal vielleicht bei notwendiger Verkapselung von Daten in einem Modul, die mittels einer Setter Funktion gesetzt werden sollen. Bevor man sowas macht sollte man sein Design nochmal überdenken. Wenn du es mehr als maximal einmal verwendest, hast du eigentlich immer ein kränkelndes Design.
Und im vorliegenden Beispiel würden die aktuellen Farben auf den Flächen ja in irgendeiner Weise von einem `Würfel`-Objekt gekapselt, welches man als Argument übergeben kann und nicht "global" auf Modulebene bekannt machen muss.
-
- User
- Beiträge: 38
- Registriert: Samstag 24. November 2007, 16:50
Also global gilt es, bei etwas größeren Programmen, zu vermeiden.
Sollte möglich sein, danke.
Hab grad bisschen bei Thinking in Tkinter herumgelesen und auch verschiedenes ausprobiert.
Dabei haben sich mir wieder ein paar Fragen gestellt:
Erstens:
Warum definiert der Autor, von Thinking in Tkinter, die root = Tk() und die mainloop-Anweisung immer außerhalb der Klasse und übergibt root dann als Parameter?
Hat das einen Vorteil gegenüber dem, wenn man auch diese Anweisungen mit in die Klasse packt? Bin verunsichert, da ich bei anderen "Anleitungen" diese immer in der Klasse definiert gefunden habe.
Zweitens:
Funktioniert beides.
Warum stellt Python zwei Möglichkeiten zur verfügung? Ist das nicht sinnlos?
Oder sollte man eine der beiden eh nicht verwenden, da sie in späteren Versionen von Python nicht mehr vorhanden sein wird?
Drittens:
Habe im irgendwo gelesen, dass man Längeneinheiten bei Tkinter auch in Zentimeter, Millimeter und Inch angeben kann.
Das funktioniert bei Canvas auch ausgezeichnet:
Wenn ich das ganze allerdings bei einem Button versuche funktioniert es nicht, obwohl es, laut Beschreibung, für alle Widgets von Tkinter funktionieren sollte:
Viertens und Letztens:
Warum braucht mein Computer so lange um die Buttons zu plazieren?
Wenn man sich Minesweeper anschaut funktioniert das ja erheblich schneller .
Also was mach ich falsch?
Code:
Sollte möglich sein, danke.
Hab grad bisschen bei Thinking in Tkinter herumgelesen und auch verschiedenes ausprobiert.
Dabei haben sich mir wieder ein paar Fragen gestellt:
Erstens:
Warum definiert der Autor, von Thinking in Tkinter, die root = Tk() und die mainloop-Anweisung immer außerhalb der Klasse und übergibt root dann als Parameter?
Hat das einen Vorteil gegenüber dem, wenn man auch diese Anweisungen mit in die Klasse packt? Bin verunsichert, da ich bei anderen "Anleitungen" diese immer in der Klasse definiert gefunden habe.
Zweitens:
Code: Alles auswählen
button.pack(side=tk.LEFT)
button.pack(side='left')
Warum stellt Python zwei Möglichkeiten zur verfügung? Ist das nicht sinnlos?
Oder sollte man eine der beiden eh nicht verwenden, da sie in späteren Versionen von Python nicht mehr vorhanden sein wird?
Drittens:
Habe im irgendwo gelesen, dass man Längeneinheiten bei Tkinter auch in Zentimeter, Millimeter und Inch angeben kann.
Das funktioniert bei Canvas auch ausgezeichnet:
Code: Alles auswählen
import Tkinter as tk
root = tk.Tk()
canvas = tk.Canvas(root, width='10c', height='10c')
canvas.pack()
root.mainloop()
Code: Alles auswählen
button = tk.Button(root, width='10c', height='10c')
button.pack()
Viertens und Letztens:
Warum braucht mein Computer so lange um die Buttons zu plazieren?
Wenn man sich Minesweeper anschaut funktioniert das ja erheblich schneller .
Also was mach ich falsch?
Code:
Code: Alles auswählen
import Tkinter as tk
class MyApp(object):
def __init__(self, myParent):
self.myParent=myParent
myContainer1 = tk.Frame(self.myParent)
myContainer1.pack()
self.button = self.buttonDict(width=25)
for i in xrange(25):
for o in xrange(25):
self.button[i][o] = tk.Button(myContainer1, width=2, height=1)
self.button[i][o].grid(row=i, column=o)
def buttonDict(self,width):
button = []
for i in xrange(1,width*width,width):
button += [[['button%u' %(i+dummy)] for dummy in xrange(width)]]
return button
root = tk.Tk()
myapp = MyApp(root)
root.mainloop()
Das scheint mir ein bisschen Geschmackssache zu sein. Bei Shipman z.B. findet es z.B. wieder ganz anders (http://infohost.nmt.edu/tcc/help/pubs/t ... l-app.html).smashed to pieces hat geschrieben:Warum definiert der Autor, von Thinking in Tkinter, die root = Tk() und die mainloop-Anweisung immer außerhalb der Klasse und übergibt root dann als Parameter?
Hat das einen Vorteil gegenüber dem, wenn man auch diese Anweisungen mit in die Klasse packt? Bin verunsichert, da ich bei anderen "Anleitungen" diese immer in der Klasse definiert gefunden habe.
Soweit ich mich erinnere, hat das mit Tk/Tcl zu tun und irgendeiner Abwärtskompatibilität. Nach meiner Einschätzung ist die Variante mit den Konstanten in Großbuchstaben die gebräuchlichere, weil es eher der allgemeinen Konvention im Umgang mit Konstanten entspricht. Es gibt aber mindestens einen Fall (ich glaube, es war irgendein Button-Zustand), wo es NUR mit der String-Variante möglich ist, weil keine entsprechende Konstante existiert.smashed to pieces hat geschrieben:Funktioniert beides.Code: Alles auswählen
button.pack(side=tk.LEFT) button.pack(side='left')
Warum stellt Python zwei Möglichkeiten zur verfügung? Ist das nicht sinnlos?
Oder sollte man eine der beiden eh nicht verwenden, da sie in späteren Versionen von Python nicht mehr vorhanden sein wird?
Bei Buttons, die mit Text (und nicht mit einem Image) belegt werden, gibt width/height die Breite/Höhe in Zeichen an. Da funktioniert das nicht. Wenn man ein Icon drauflegt, dann sollte es funktionieren (laut Doku - ausprobiert habe ich es noch nicht).smashed to pieces hat geschrieben:Habe im irgendwo gelesen, dass man Längeneinheiten bei Tkinter auch in Zentimeter, Millimeter und Inch angeben kann. Das funktioniert bei Canvas auch ausgezeichnet: [...]
Wenn ich das ganze allerdings bei einem Button versuche funktioniert es nicht, obwohl es, laut Beschreibung, für alle Widgets von Tkinter funktionieren sollte:
Bei mir sind die Buttons nach dem Start sofort alle da.smashed to pieces hat geschrieben:Warum braucht mein Computer so lange um die Buttons zu plazieren?
Was deinen Code angeht, so ist die Methode buttonDict überflüssig und auch der Name ist schlecht gewählt, weil es kein Dictionary ist, sondern eine zweidimensionale Liste. Die Zeile
Code: Alles auswählen
self.button = self.buttonDict(width=25)
Code: Alles auswählen
self.button = [[None]*25 for k in xrange(25)]
Nachtrag/Korrektur: Der eine Fall, wo es keine Konstante zur Zeichenkettenvariante gibt, ist der Readonly-Zustand eines Entry-Widgets.
Während es für "normal" und "disabled" die passenden Konstanten tk.NORMAL und tk.DISABLED gibt, gilt dies für "readonly" nicht. Interessanterweise ist der "readonly"-Zustand zwar für Entry-Widgets definiert, nicht aber für Text-Widgets.
Während es für "normal" und "disabled" die passenden Konstanten tk.NORMAL und tk.DISABLED gibt, gilt dies für "readonly" nicht. Interessanterweise ist der "readonly"-Zustand zwar für Entry-Widgets definiert, nicht aber für Text-Widgets.
Die meisten Tkinter-Konstanten (wenn nicht gar alle) sind als Zeichenketten definiert:
IMHO ist es aber besser den Namen als die Zeichenkette zu verwenden weil man dann auf den ersten Blick sieht, dass es sich um eine Konstante handelt und der Interpreter auch an Stellen mit einem `NameError` auf Fipptehler reagiert, wo eine falsch geschriebene Zeichenkette vielleicht "lautlos" durchgeht, aber eben nicht richtig funktioniert.
Bei dem Geschwindigkeitsproblem könntest Du mal das "pack"en des `Frame` hinter die Schleife mit den `Button`\s verschieben. Sonst kann es eventuell passieren, dass durch jeden der 625 Knöpfe das Layout neu berchnet und die Anzeige aktualisiert wird.
Code: Alles auswählen
In [82]: tk.LEFT
Out[82]: 'left'
Bei dem Geschwindigkeitsproblem könntest Du mal das "pack"en des `Frame` hinter die Schleife mit den `Button`\s verschieben. Sonst kann es eventuell passieren, dass durch jeden der 625 Knöpfe das Layout neu berchnet und die Anzeige aktualisiert wird.
Hallo smashed to pieces
Die Konstante:
stammt aus dem Skript 'Tkconstants.py', welches durch das Tkinter-Hauptskript 'Tkinter.py' mittels Sternchen-Import importiert wird. Das Skripts ist unter dem Pfad ...python/lib-tk/ auffindbar. Da diese Konstanten in deinem Programm-Skript durch das Tkinter-Modul Tkinter as tk importiert werden braucht es noch das tk. vor der Konstante. Du kannst nach dem import von Tkinter as tk noch das Modul Tkconstants mit Sternchenimport (unschön) importieren dann braucht es das tk. nicht mehr. Schau einmal in das Skript Tkconstants.py. Dort siehst du fast alle Konstanten die für Tkinter-Widgets gebraucht werden. Ich perönlich brauche meistens die Strings an Stelle der Konstanten.
Betreffs Geschwindigkeitssteigerung könntest du IMHO durch den Ersatz der Button-Widgets mittels Canvas 'Rectangle-Objekte' platziert auf einem Canvas-Widget noch eine Steigerung erreichen. Allerdings ohne den Einsatz des Pack-Managers.
Gruss wuf
Die Konstante:
Code: Alles auswählen
button.pack(side=tk.LEFT)
Betreffs Geschwindigkeitssteigerung könntest du IMHO durch den Ersatz der Button-Widgets mittels Canvas 'Rectangle-Objekte' platziert auf einem Canvas-Widget noch eine Steigerung erreichen. Allerdings ohne den Einsatz des Pack-Managers.
Gruss wuf
Take it easy Mates!