komme nicht weiter
Jedes Mal wenn du login() aufrufst, erfolgt auch ein print(), da dies im Code der Funktion enthalten ist. Was am Ende mit dem Ergebnis passiert, spielt dafür keine Rolle.
``result`` macht schon was, denn es nimmt die Rückgabe des Funktionsaufrufs an. In Python geben Funktionen ohne ``return`` immer automatisch ``None`` zurück.
(und ohne ``yield``, aber das muss man als Anfänger nicht wissen)
``result`` macht schon was, denn es nimmt die Rückgabe des Funktionsaufrufs an. In Python geben Funktionen ohne ``return`` immer automatisch ``None`` zurück.
(und ohne ``yield``, aber das muss man als Anfänger nicht wissen)
"result" ist ein Name. Dem wird hier ein Wert zugewiesen (linke Seite vom = ). Wie denkst du, könnte das etwas tun?StMan hat geschrieben: Donnerstag 29. Januar 2026, 20:33 ich denke mit login(sammelstring) wird der sammelstring an def(): übergeben, result macht nix, den es gibt ja kein return.
Code: Alles auswählen
login(sammelstring) # Ruft die Funktion "login" auf und übergibt als einzigen Parameter semmelstring
result = login(name) # Ruft die Funktion "login" auf, übergibt als einzigen Parameter "name" und bindet den Rückgabewert (return value) an den Namen result.
- __blackjack__
- User
- Beiträge: 14285
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@StMan: Anmerkungen zum Quelltext:
Womit prüfst Du denn Typannotationen? Die `login()`-Funktion gibt keine Zeichenkette zurück, da sollte also eigentlich ein Fehler beim prüfen gemeldet werden. Falls Du die Typannotationen nicht mit einem Programm prüfst, solltest Du besser auch keine machen, denn falsche Typannotationen sind noch schlechter als falsche Dokumentation oder Kommentare, denn auf Typannotationen verlässt sich der Leser, weil er davon ausgeht, dass die geprüft wurden.
Eingerückt wird per Konvention mit vier Leerzeichen pro Ebene. Siehe auch den Style Guide for Python Code.
Namen klein_mit_unterstrichen, ausser Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Und keine kryptischen Abkürzungen als Pre- oder Suffix oder gar nur eine Abkürzung als Name. Also `entry` statt `e`, `password` statt `pw`, kein unverständliches `eg_` vor Namen, und so weiter.
Funktionen (und Methoden) bekommen alles was sie ausser Konstanten benötigen als Argument(e) übergeben. Es sollte keinen globalen Zustand auf Modulebene geben. Hier fehlt eine eigene Klasse.
GUI nicht als Ablage für Werte missbrauchen. Es gibt keinen sinnvollen Grund einen Text per `cget()` von einem Widget abzufragen und den dann irgendwie weiter zu verarbeiten. Dann stimmt die Trennung von Programmlogik und GUI nicht.
Eine Funktion die `check_entries()` heisst, sollte nur das machen was der Name naheliegt und keine Anmeldung.
Einer Anmeldung die Anmeldedaten als eine Zeichenkette zusammengesetzte Zeichenkette zu übergeben ist komisch bis falsch. Die Funktion wird das doch nur wieder auseinander nehmen müssen.
Erst mit Listen und „comprehension“-Syntax die Werte abfragen und zu testen, um sie danach dann noch mal in einzelnen Anweisung abzufragen ist umständlich und doppelt. Entweder die Liste weiterverarbeiten, oder aber erst die einzelnen Werte abfragen und dann erst auf die Bedingung(en) testen.
Womit prüfst Du denn Typannotationen? Die `login()`-Funktion gibt keine Zeichenkette zurück, da sollte also eigentlich ein Fehler beim prüfen gemeldet werden. Falls Du die Typannotationen nicht mit einem Programm prüfst, solltest Du besser auch keine machen, denn falsche Typannotationen sind noch schlechter als falsche Dokumentation oder Kommentare, denn auf Typannotationen verlässt sich der Leser, weil er davon ausgeht, dass die geprüft wurden.
Eingerückt wird per Konvention mit vier Leerzeichen pro Ebene. Siehe auch den Style Guide for Python Code.
Namen klein_mit_unterstrichen, ausser Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Und keine kryptischen Abkürzungen als Pre- oder Suffix oder gar nur eine Abkürzung als Name. Also `entry` statt `e`, `password` statt `pw`, kein unverständliches `eg_` vor Namen, und so weiter.
Funktionen (und Methoden) bekommen alles was sie ausser Konstanten benötigen als Argument(e) übergeben. Es sollte keinen globalen Zustand auf Modulebene geben. Hier fehlt eine eigene Klasse.
GUI nicht als Ablage für Werte missbrauchen. Es gibt keinen sinnvollen Grund einen Text per `cget()` von einem Widget abzufragen und den dann irgendwie weiter zu verarbeiten. Dann stimmt die Trennung von Programmlogik und GUI nicht.
Eine Funktion die `check_entries()` heisst, sollte nur das machen was der Name naheliegt und keine Anmeldung.
Einer Anmeldung die Anmeldedaten als eine Zeichenkette zusammengesetzte Zeichenkette zu übergeben ist komisch bis falsch. Die Funktion wird das doch nur wieder auseinander nehmen müssen.
Erst mit Listen und „comprehension“-Syntax die Werte abfragen und zu testen, um sie danach dann noch mal in einzelnen Anweisung abzufragen ist umständlich und doppelt. Entweder die Liste weiterverarbeiten, oder aber erst die einzelnen Werte abfragen und dann erst auf die Bedingung(en) testen.
“Programming is partially an artform and, like artists, programmers will do it even if they don't get money.” — Linus Torvalds
Hier mal ein Beispiel, wie eine Aufteilung in GUI und Applikationslogik aussehen könnte:
Code: Alles auswählen
import tkinter as tk
from tkinter import ttk, messagebox
class Application:
def login(self, host, username, password):
print(f"Attempting login for user: {username} at {host}")
class LoginWindow:
def __init__(self, root, app):
self.root = root
self.app = app
root.title("Login")
root.resizable(False, False)
pad = {"padx": 8, "pady": 6}
frame = ttk.Frame(root)
frame.grid(column=0, row=0, sticky="nsew")
# Host
ttk.Label(frame, text="Host:").grid(column=0, row=0, sticky="w", **pad)
self.host_var = tk.StringVar(value="localhost")
ttk.Entry(frame, textvariable=self.host_var, width=30).grid(column=1, row=0, **pad)
# Username
ttk.Label(frame, text="Username:").grid(column=0, row=2, sticky="w", **pad)
self.user_var = tk.StringVar()
ttk.Entry(frame, textvariable=self.user_var, width=30).grid(column=1, row=2, **pad)
# Password
ttk.Label(frame, text="Password:").grid(column=0, row=3, sticky="w", **pad)
self.password_var = tk.StringVar()
ttk.Entry(frame, textvariable=self.password_var, show="*", width=30).grid(column=1, row=3, **pad)
# Buttons
button_frame = ttk.Frame(frame)
button_frame.grid(column=0, row=4, columnspan=2, pady=(6, 0))
ttk.Button(button_frame, text="Connect", command=self.on_connect).grid(column=0, row=0, padx=4)
ttk.Button(button_frame, text="Quit", command=root.destroy).grid(column=1, row=0, padx=4)
# Status label
self.status_var = tk.StringVar(value="")
ttk.Label(frame, textvariable=self.status_var, foreground="blue").grid(column=0, row=5, columnspan=2, **pad)
# store connection
self.conn = None
def on_connect(self):
host = self.host_var.get().strip()
user = self.user_var.get().strip()
password = self.password_var.get()
if not host or not user:
messagebox.showwarning("Missing fields", "Please provide host and username.")
return
try:
self.app.login(host, user, password)
except Exception as e:
messagebox.showerror("Login failed", str(e))
def main():
app = Application()
root = tk.Tk()
_ = LoginWindow(root, app)
root.mainloop()
if __name__ == "__main__":
main()Hallo zusammen,
Erstmal HERZLICHEN DANK an alle die versuchen mich in die richtige Spur zu bringen.
Ich habe mal eine Grundsätzliche Frage:
Sollte man die ganzen Classen in z.B im Hauptfenster_main.py unterbringen, oder sollte man das schlank halten, und die Classen in andere .py's auslagern ?
Erstmal HERZLICHEN DANK an alle die versuchen mich in die richtige Spur zu bringen.
Ich habe mal eine Grundsätzliche Frage:
Sollte man die ganzen Classen in z.B im Hauptfenster_main.py unterbringen, oder sollte man das schlank halten, und die Classen in andere .py's auslagern ?
Gruß Manfred
