Das deutsche Python-Forum

Hi,

das was jetzt kommt ist nichts besonderes, und richtet sich ausdrücklich an Leute wie mich, denen nicht so wirklich klar ist wozu OOP eigentlich gut ist (also jetzt hab ichs kapiert). Überlegt einfach mal wie umständlich es wäre diesen Code um mehrere Anweisungen für die Menschen zu erweitern, wenn man nicht OOP benutzt.

Code: Alles auswählen

import random
from string import ascii_lowercase
class Mensch:
    def __init__(self):
        global Namen
        Namen = ['Alexander', 'Markus', 'Bert', 'Katharina', 'Sabrina', 'Vera', 'Colin', 'Daniel', 'Benedikt', 'Christian', 'Christoph', 'Gregor', 'Martin', 'Nicole', 'Jasmin', 'Sandra', 'Anke', 'Jack', 'Julia']
        self.Name = random.choice(Namen)
        self.Alter = random.randint(1,90)
    def Identifikation(self):
        Schwarm = random.choice(Namen)
        if Schwarm == self.Name:
            Schwarm = random.choice(Namen)
        print (self.Name)
        print (self.Alter)
        print ('Ich bin verliebt in ' + Schwarm)
        


Element = 1
ABC = ascii_lowercase
Zahl = random.randint(10,24)
for i in range(Zahl):
    print (ABC[Element])
    new_Instance = ABC[Element]
    New_Instance = Mensch()
    New_Instance.Identifikation()
    Element = Element + 1

Also, wie gesagt: Keine Glanzleistung, aber vielleicht für jemanden nützlich (also bitte nicht als Spam löschen).

Wirklich keine Glanzleistung. Was zum Henker soll dieser `ABC`-Blödsinn? Und `Element`!? Und die Klammern bei den ``print``-Anweisungen?

Und warum fällt Dir nicht auf, dass dieser Quelltext gar nicht läuft weil Zeile 26 in einem `NameError` endet!?

Edit: Okay, kein `NameError`, habe nicht daran gedacht das es ``global`` gibt. ``global`` ist böse, bitte entfernen und so schreiben dass es ohne geht.

Einen zwingenden Grund für OOP kann ich in dem Beispiel übrigens nicht erkennen. Das hätte man auch mit einem Dictionary und Funktionen schreiben können.

Dieser ABC-Blödsinn, so wie er hier steht, wurde mir in diesem Forum so empfohlen.
Element habe ich als Variablennamen gewählt, da man schließlich von einem Element der Liste soundso spricht. Und warum ist global böse?

Den ABC-Kram verstehe ich nicht. Ist einfach eine sehr komplizierte Methode, um die Buchstaben von b an aufsteigend auszugeben. Vielleicht hast du damit noch was anderes vor, aber das

Code: Alles auswählen

new_Instance = ABC[Element]

in zeile 24 ist ueberfluessig, da es in der naechsten Zeile wieder ueberschrieben wird.

global ist genau aus dem Grund boese, der BlackJack verwirrt hat: Sie machen Programme unuebersichtlich. Wenn du mal ein paar mehr Klassen und Funktionen hast, die alle globals benutzen, ist es nur sehr schwer zu ueberblicken, welche Abhaengigkeiten zwischen welchen Funktionen und Klassen bestehen. Vergiss am besten, dass es global gibt, man braucht es wirklich aeusserst selten. Da due die Namen ja nur innerhalb der Mensch-Klasse benoetigst, sie ausserdem fuer jedes Objekt gleich sein sollen, waere hier eine Klassenvariable angebracht.

Schau dir ausserdem mal PEP 8 an, es ist ueblich, Variablennamen und Funktionsnamen klein zu schreiben.

Warum du in der for-Schleife immer noch die Variable Element hochzaehlst, obwohl du ja schon i als Schleifenzaehler hast, ist auch raetselhaft.

EDIT: In Pep 8 steht auch drin, dass Zeilenlaengen nicht laenger als 80 Zeichen sein sollten. Seitwaertsscrollen ist nervig...

Imperator hat geschrieben:Dieser ABC-Blödsinn, so wie er hier steht, wurde mir in diesem Forum so empfohlen.

Wer hat dir denn empfohlen, eine falsche Datenstruktur für ein Problem zu wählen?

Und ganz ehrlich, eine saubere OOP-Lösung würde eigentlich ganz anders aussehen.

Der ganze Code ab Zeile 19 ist genau so ein Fall von "was hat sich der Autor dabei gedacht". Wenn ich es mir so oberflächlich ansehe, habe ich nicht die geringste Ahnung, zu was das führen soll.

Das Programm erzeugt uebrigens eine ueberdurschnittlich hohe Rate an Homosexuellen.

Und es koennen Leute in jemanden verliebt sein, den es garn nicht gibt...

Imperator hat geschrieben:Dieser ABC-Blödsinn, so wie er hier steht, wurde mir in diesem Forum so empfohlen.

Eigentlich wurdest du doch nur darauf hingewiesen, das du "abcde..." durch string.ascii_lowercase ersetzen solltest.
Noch eine, in diesem Fall vlt. bessere Möglichkeit:

Code: Alles auswählen

for i in xrange(Zahl):
    print chr(i+96)

Ausserdem fördert es das Vorurteil(?), das Homosexuelle keine dauerhaften Beziehungen eingehen. Sehr beständig ist das Verliebtsein ja nicht. Vielleicht handelt es sich bei `Mensch` ja um die Art Wesen, die in diesen komischen Vorabend-Soaps rumwuseln…

@Rebecca: Bei dem Quelltext muss man ganz genau hinsehen: Die Zuweisung in Zeile 24 wird danach nicht gleich wieder überschrieben.

BlackJack hat geschrieben: @Rebecca: Bei dem Quelltext muss man ganz genau hinsehen: Die Zuweisung in Zeile 24 wird danach nicht gleich wieder überschrieben.

...aber dennoch nicht verwendet (und so im nächsten loop überschrieben, was ja aber auch nix macht).

... ist noch was zum Zerfetzen übrig?

OK, das mit dem verliebt sein, muss noch optimiert werden.
Diese Sachen mit den Variablen, sind deshalb so, weil ich das Programm von vornherein darauf ausgelegt habe, es mal weiterzuentwickeln. aber auf den Style-Guide pfeif ich.

Nachtrag: Ich habe übrigens von anfang an geschrieben, dass das ein Beispiel dafür sein soll wozu OOP gut ist, und nicht, dass es ein Musterprogramm ist.

Jan-Peer hat geschrieben:... ist noch was zum Zerfetzen übrig?

Jo, man sollte Quellcode immer kommentieren

Dann ist es für jeden leichter. Selbst der Verfasser könnte sich später fragen, warum er eine bestimmte Sache so und nicht so gelöst hat.

Imperator hat geschrieben:Nachtrag: Ich habe übrigens von anfang an geschrieben, dass das ein Beispiel dafür sein soll wozu OOP gut ist, und nicht, dass es ein Musterprogramm ist.

Ja, mag alles sein. Trotzdem solltest Du froh sein, das alle die hier gepostet haben, Dir eigentlich nur helfen wollten. Das man dabei ganz automatisch, ob positiv oder negativ, Kritik einstecken muss/sollte, ist irgendwie ganz logisch. Jeder will irgendwie nur vermitteln, das ginge auch so, oder so. Andererseits soll Dein Muster andere User nicht verwirren. Denn so wie BlackJack es zum Anfang schrieb, es hätte für Dein "Muster" auch eine Nicht-OOP-Programierweise ausgereicht.

Gruß Andy

@Imperator: Es ist aber kein gutes Beispiel dafür wozu OOP gut ist. Das was OOP an Mehrwert bringt sind Polymorphie und Vererbung. Beides ist im Beispiel nicht zu sehen.

Und was total überflüssige Variablen und Quelltext mit Erweiterbarkeit zu tun haben ist mir auch nicht so ganz klar. Die `ABC` Geschichte hinterlässt eher den Eindruck dass Du keine Ahnung hast was Du da tust und das eher "programming by accident" ist. Das wird durch die Behauptung man habe Dir das hier so gesagt, noch unterstrichen.

Es ist kein gutes OOP-Beispiel und ein schlechtes Programmbeispiel. Wenn Leute die schon programmieren können verwirrt werden, was soll das dann bei Einsteigern bringen!?

Mit der Trotzhaltung gegenüber dem Style Guide punktest Du auch nicht nicht gerade. Klar gibt es da abweichende Meinungen ─ über mixedCase, CapWords oder kleine_worte_mit_unterstrichen bei Attributen und Funktionsnamen kann man streiten, aber ALL_CAPS für etwas was keine Konstante ist oder etwas anderes als CapWords für Klassen sind IMHO nicht "verhandelbar". Das verwirrt einfach zu viele Leser weil das sprachübergreifend Assoziationen bei Programmierern weckt, mit denen man besser nicht brechen sollte.

hier mal ein swinger

Code: Alles auswählen

from random import choice
Namen = [   'Alexander', 'Markus', 'Bert', 
            'Katharina', 'Sabrina', 'Vera', 
            'Colin', 'Daniel', 'Benedikt', 
            'Christian', 'Christoph', 'Gregor', 
            'Martin', 'Nicole', 'Jasmin',
            'Sandra', 'Anke', 'Jack', 'Julia' ] 
def verliebt_in():  
    return ' ich bin verliebt in '.join([choice(Namen or Namen) for i in range(10)])
print verliebt_in(),

edit: Hallo Imperator wollte nur sagen, sorry wenn ich es hier einfach reingepostet habe. Zu OOP wurde aber schon alles gesagt.

Gruss
pyStyler

Wenn PEP 8 eine Instanz einer Subklasse von Chuck Norris wäre, hätte sie jetzt einige Roundhouse-Kicks verteilt!

Leute, Leerzeilen! Nach und zwischen Imports, ebenso zwischen Funktions-/Methodendefinitionen usw. usf.

Imperator hat geschrieben:Diese Sachen mit den Variablen, sind deshalb so, weil ich das Programm von vornherein darauf ausgelegt habe, es mal weiterzuentwickeln. aber auf den Style-Guide pfeif ich.

Also du postest ein Beispielprogram welches bewusst gegen gängige Konventionen verstößt? Halte ich für eher nicht optimal.

Mhm... Ein gutes OOP Beispeil wäre eher gewesen, wenn du "Mensch" tatsächlich als Objekt gesehen hättest. Du betrachtest jedoch eher eine Aktion als Objekt... Böser Pseudogedankencode, der kein Python ist sondern nur'ne Überlegung!!!!:

Code: Alles auswählen

class Mensch:
    def __init__(self, name, geburtsjahr, groesse):
        self.name = name
        self.geburtsjahr = geburtsjahr
        self.groesse = groesse

    def verlieben(self, menschinstanz):
        self.verliebt = menschinstanz

    @property
    def alter(self):
        return momentanes_jahr - self.geburtsjahr

marcell = Mensch('Marcell', 1989, 175)
randomfrau = Mensch('frau', 1990, 156)
marcell.verlieben(randomfrau)
print marcell.verliebt.name #Für den Namen von der Frau... und sowas...

Ich weise nochmal darauf hin, dass das kein valides Python ist oder sowas, sondern nur dämlicher Pseudocode!! Aber hier kristallisiert sich halt heraus, was'n Objekt überhaupt darstellt. Ihr könnt mich gerne berichtigen, wenn irgendas idiotisch ist... (Außerdem find ich es doof, dass man sich zufällig verliebt x3)

@PEP8: Naja, ich halte mich zum größten Teil auch daran, aber nur weil es meinem eigenen Stil entspricht. Ich mag halt ``name_mit_unterstrichen`` und CamelCase für Klassen und vieles mehr. Ansonsten würde ich mich nicht daran halten

Was ich eigentlich sagen will ist, was mir am meisten an der **Deutschen** Python Community negativ aufstößt ist die allgemeine Versessenheit auf PEP8 und den Zen. Als ob man es mit religiösen Spinnern zu tun hat

Nicht falsch verstehen aber einige hier sind so dermaßen darauf versessen das es mit einer Sekte zu vergleiche ist

Schade eigentlich...

Da finde ich die Ruby Community um einiges angenehmer

Weniger religöse Spinner...

Versucht es erstmal nicht in den falschen hals zu bekommen (Auch wenn es schwer ist) sonder seht es mal so:
1. wenn eine Gemeinschaft an einem Programm arbeitet sind Styleguids oberste Pflicht um ein konsistentes Erscheinungsbild zu hinterlassen (=clean)!! Ob man sich da nun an PEP8 richtet oder selber was ausarbeitet ist sowas von irrelevant[1] . Wichtig ist, das man sich auf einen gemeinsamen Stil geeinigt hat!

2. Die meisten hier sind doch eher Hoby-Programmierer die Python für sich entdeckt haben um alltägliche Probleme zu lösen oder gar die Lösungen dafür mit Python zu automatisieren. Wenn dann einer hier fragt was er bei seiner Lösung falsch gemacht hat, finde ich es total daneben ihn immer und wider auf PEP8 und Zen hinzuweisen. Das ist nicht nur penetrant und arrogant sondern auch lästig

Denn er will ja gerne einen Denkanstoß/Lösung für sein Problem und nicht über Stylguids debattieren und sich für **seinen** Stil rechtfertigen. Tut nicht not oder?

[1]: Klar, jetzt könnte ihr damit ankommen und sagen das die Regeln in PEP8 sich allgemein bewährt haben und man sich daran halten muss/sollte. Dan kommen ich euch mit einer menge Gegenargumente und genug belegen in den gezeigt wird das auch ganz andere Styleguids funktionieren; auch durchaus für Python

P.S.: Nur mal so als Denkanstoß.

Der Sinn von PEP8 ist nicht nur, Code lesbar und logisch zu machen, denn das kriegen viele andere Styleguides auch schon hin. Der Sinn ist einfach Einheitlichkeit. Bei C++, Ruby, Perl und Java sieht man oft, wie die Leute ihr eigens Süppchen kocht, man muss sich in jeden Quelltext logisch und strukturell reindenken. Bei den meisten größeren Sachen in Python wird PEP8 als Grundstruktur genommen, was zu einem sehr schnellen Verständnis führt.

Das deutsche Python-Forum

Simples OOP

Simples OOP