Schleife stoppen

[Artur]

Alles klar. Liste ist erstellt. Funzt auch. Über die Formel mache ich mir ein andermal Gedanken

[JonasR]

Über die Formel mache ich mir ein andermal Gedanken

...Die `isleap()`-Funktion aus dem `calendar`-Modul.

... *Hust* *räusper* *verend*

Edit:

Code: Alles auswählen

>>> import calendar
>>> calendar.isleap(2000)
True
>>> calendar.isleap(1700)
False
>>> calendar.isleap(1804)
True
>>> calendar.isleap(1992)
True
>>> calendar.isleap(1993)
False
>>> calendar.isleap(1994)
False

[/me]

Über die Formel mache ich mir ein andermal Gedanken

Code: Alles auswählen

def is_leap_year(year):
    return (not year % 4) and (year % 100) or (not year % 400)

[problembär]

@problembär: Ach, das ist dann jetzt plötzlich kein Modul-Gefrickel was man besser selber noch mal mit den eingebauten Mitteln lösen sollte!?

Schön, daß Du Dich noch an die Freundlichkeiten erinnerst, die wir ausgetauscht hatten. An Deine erinnere ich mich auch noch ganz gut. Ist doch schade. Wäre es nicht harmonischer gewesen, sich gleich mit mehr Höflichkeit und Toleranz zu begegnen?

Aber zum Problem: Ich habe keine Idee, wie man ein Schaltjahr sicher von Hand berechnet (mal angenommen, ich hätte die Postings hier gerade nicht gelesen). Ich habe auch keine große Lust, darüber nachzudenken. Es gibt ein Modul, in dem das schon fertig geschrieben ist. Na ja, dann setze ich es eben ein. Ok, das ist natürlich keine so gute Idee, wenn der Lehrer die Berechnung von Hand sehen will. Aber sonst schon.
Module halte ich also für sinnvoll, um codiertes Wissen für Spezialprobleme abzurufen. Ich setze sie nur nicht so gern bei der grundlegenden Datenverarbeitung ein.
Aber auch das soll jeder für sich selbst entscheiden.

[EyDu]

Module halte ich also für sinnvoll, um codiertes Wissen für Spezialprobleme abzurufen. Ich setze sie nur nicht so gern bei der grundlegenden Datenverarbeitung ein.

Kannst du auch begründen, warum du das so machst? Bei jedem Ausschlagen von bereits vorhandenem Code verzichtest du auf bereits inverstierte Gedanken, getesteten Code, baust selber noch Fehler ein, produzierst höheren Aufwand bei der Wartbarkeit und investierst häufig wertvolle Zeit, welche man auch für nützliche Dinge hätte einsetzen können.

[/me]

Kannst du auch begründen, warum du das so machst? Bei jedem Ausschlagen von bereits vorhandenem Code verzichtest du auf bereits inverstierte Gedanken, getesteten Code, baust selber noch Fehler ein, produzierst höheren Aufwand bei der Wartbarkeit und investierst häufig wertvolle Zeit, welche man auch für nützliche Dinge hätte einsetzen können.

Das "selbst machen!" scheint irgendwie die klassische Ansicht eines Programmierers zu sein. Häufig gewöhnt man sich das aber wieder ab.

Ich erinnere mich an eine Begebenheit, die inzwischen fast 20 Jahre her ist. Damals haben zwei Mitarbeiter etwa 4 Wochen gebraucht um für eine eigene Anwendung (unter Windows) zwei spezielle grafische Controls zu entwickeln. Eine Evaluierung im Nachhinein ergab, dass es solche Komponenten auf dem Markt bereits gab und dass man diese - inklusive einiger weiterer - auch für etwa 250 DM hätte lizenzieren können.

Im Endeffekt war es sowohl von der betriebswirtschaftlichen, wie auch von der IT-Seite unbefriedigend. Es wurde deutlich mehr Geld ausgegeben als nötig war und die Entwickler haben wertvolle Zeit vergeudet, die dann woanders fehlte.

[jerch]

Leider endet "Reinventing the wheel" allzu oft in "Reinventing the square wheel". Ich glaube, dass sich jeder Programmierer schonmal mit einer hausbackenen Lösung rumgeschlagen hat, um später festzustellen, dass es da was Fertiges gibt, was in macherlei Hinsicht besser gewesen wäre (bessere Skalierung, einfache Integration, Stichwort Orthogonalität etc.).
Gerade im Umfang der Standardbibliothek liegt eine Stärke von Python - batteries included.

[/me]

Leider endet "Reinventing the wheel" allzu oft in "Reinventing the square wheel".

Die Leute die daraus nichts lernen, entwickeln dann bei der nächsten Iteration aus dem viereckigen das dreieckige Rad: "Super, es rumpelt pro Umdrehung 25% weniger!"

[snafu]

Code: Alles auswählen

int(Jahr)==(1700 or 1800 or 1900)

Das bedeutet nicht, was du glaubst, dass es bedeutet. Es bedeutet nicht: int(Jahr) ist gleich einem der Werte 1700 oder 1800 oder 1900, sondern: int(Jahr) ist gleich der Auswertung des Ausdrucks (1700 or 1800 or 1900), und der Wert dieses Ausdrucks ist die Konstante True, da a or b genau dann True ergibt, wenn nicht beide, a und b, False (oder äquivalent dazu, zB.: None oder "" oder 0 oder [] oder ...) sind.

Das stimmt so leider nicht. Der Ausdruck wird nicht zu `True`, sondern zu `1700`, was daran liegt, dass hier einfach solange seitens Python ausgewertet wird, bis etwas wahres herauskommt und das wird dann zurückgegeben. Da 1700 größer als 0 ist, wird entsprechend auch `1700` zurückgegeben. Wenn am Ende keiner der Teilausdrücke wahr ist, dann wird der letzte Teilausdruck zurückgeliefert. Man kann das ja mal für sich testen mit:

Code: Alles auswählen

0 or False or None or '' or [] or {} or ()

...und da dann nach Belieben den jeweils letzten Ausdruck entfernen.

[pillmuncher]

Das stimmt so leider nicht.

Interessant. Ich war immer der Meinung gewesen, da käme tatsächlich True oder False raus. Weil alles, was da rauskommt, entweder True-ish oder False-ish ist, hab ich es nie genau angesehen. Sachen wie:

Code: Alles auswählen

if (a or b or c) == True:
    ...

oder:

Code: Alles auswählen

if (a or b or c) is True:
    ...

habe ich nie programmiert, sondern bin immer dem reinen Katechismus gefolgt:

Code: Alles auswählen

if a or b or c:
    ...

und da ist der Unterschied True/False vs. True-ish/False-ish irrelevant, weswegen ich auch nie in das Problem reingerannt bin.

PEP 8 sagt dazu:

Code: Alles auswählen

     - Don't compare boolean values to True or False using ==

        Yes:   if greeting:

        No:    if greeting == True:

        Worse: if greeting is True:

Jetzt ist auch klar, warum.

[ProGammler88]

welcher part vom programm funktioniert denn gerade nicht oder hast du gerade ein endlosschleife am laufen?