DB-Anfänger - Tabelle mit Variablen anlegen in sqlite3

[Leonidas]

Python hat keine privaten Attribute und ``__`` steht ganz sicher nicht für "privat". Wer hat dir denn sowas erzählt?

[Hyperion]

Nein bei weitem nicht. Ich schreibe ein Interface zu einem anderen Programm. Die Parameter der Schnittstelle sollen zusätzlich in einer Datenbank abgelegt werden. Ich dachte es ist sichere ich prüfe zunächst ob die Spalte da ist, bevor ich versuche da was reinzuschreiben.

Das kapiere ich leider so immer noch nicht. Nutzt das andere Programm eine DB zum Ablegen / Auslesen der Daten? Wenn ja, dann ist die doch vorhanden und man kann davon ausgehen, dass das so ok ist!

Ich würde ja bei insert-Statements einfach dei Felder explizit angeben, in die man Werte schreiben möchte. Sollte ein Feld nicht vorhanden sein, sollte es zu einer Exception kommen, die man dann gut abfangen kann. Imho ist das ein sauberer und einfacher Weg - zumal Du bei Deinem Ansatz nicht einmal garantieren kannst, dass zwischenzeitlich niemand anders die Tabellenstruktur ändert (Stichwort Transaktion).

[BlackJack]

Insbesondere wäre ein "privat" bei *lokalen* Namen auch ziemlich eigenartig.

[BastiL]

Python hat keine privaten Attribute und ``__`` steht ganz sicher nicht für "privat". Wer hat dir denn sowas erzählt?

http://openbook.galileocomputing.de/pyt ... 9c385b9ec3

Vielleicht verstehe ich das auch falsch?

[BastiL]

Das kapiere ich leider so immer noch nicht. Nutzt das andere Programm eine DB zum Ablegen / Auslesen der Daten? Wenn ja, dann ist die doch vorhanden und man kann davon ausgehen, dass das so ok ist!.

So ist es im wesentlichen gedacht. Das Programm soll aber die Datenbank selbst verwalten und bei Bedarf (einmal im Jahr) eine neue Datenbank samt der dann nötigen Tabellen erzeugen.

Ich würde ja bei insert-Statements einfach dei Felder explizit angeben, in die man Werte schreiben möchte. Sollte ein Feld nicht vorhanden sein, sollte es zu einer Exception kommen, die man dann gut abfangen kann. Imho ist das ein sauberer und einfacher Weg - zumal Du bei Deinem Ansatz nicht einmal garantieren kannst, dass zwischenzeitlich niemand anders die Tabellenstruktur ändert (Stichwort Transaktion).

Hmm also einfach die Abfrage weglassen und die exception abfangen?

[EyDu]

http://openbook.galileocomputing.de/pyt ... 9c385b9ec3

Vielleicht verstehe ich das auch falsch?

Dieses Buch ist wirklich ein Fluch. Und das Kapitel über Objektorientierung ist mit Abstand das schlimmste. Wenn du das Buch in Papierform hast, dann ist es schade um die Bäume, sonst solltest du einfach nur den Link löschen. Wenn du mehr über das Openbook erfahren möchtest, dann benutze mal die Suchfunktion.

Jetzt suchst du dir am besten ein vernünftiges Tutorial und vergisst alles was du in dem Buch gelesen hast. Im Wiki sind einige vernünftige Tutorials aufgeführt. Wenn du dich nicht entscheiden kannst, dann nimm einfach "A Byte of Python".

[BastiL]

Danke, schon wieder was gelernt. Ich werde mich da mal reinlesen.

Zurück zu meinem aktuellen Problem - eine Möglichkiet ist auf die Konsitenz der Datenstrukturen zu vertrauen und die Exception abzufangen. Aber wie könnte ich denn jetzt mit den Tupeln arbeiten? Die bekomme ich ja auch zurück, wenn ich Daten aus der Datenbank auslese, oder?

[Hyperion]

So ist es im wesentlichen gedacht. Das Programm soll aber die Datenbank selbst verwalten und bei Bedarf (einmal im Jahr) eine neue Datenbank samt der dann nötigen Tabellen erzeugen.

Dann würde ich ...
1) wenn ich "from scratch" anfange und kein ORM verwenden will: ein SQL-Script Datei erstellen, in dem alle zur Generierung notwendigen Anweisungen drin stehen

2.) wenn eine DB bereits vorhanden ist: ein Backup der create-Statements ziehen

Das Script führst Du dann 1x im Jahr aus (oder lässt es eben automatisiert ausführen aus Deinem Script heraus).

Hmm also einfach die Abfrage weglassen und die exception abfangen?

Na so nützen Sie die eh nix - es kann ja jemand in der Zeit zwischen Abfrage und inserts die Struktur ändern! Also Exceptions abfangen ist imho eine gute Idee und recht "pythonic" [wiki]Allgemeine Begriffe#E[/wiki]

[frabron]

Python hat keine privaten Attribute und ``__`` steht ganz sicher nicht für "privat". Wer hat dir denn sowas erzählt?

http://openbook.galileocomputing.de/pyt ... 9c385b9ec3

Vielleicht verstehe ich das auch falsch?

Das steht übrigens auch in "Dive into Python" drin: http://diveintopython.org/object_orient ... tions.html

und im offiziellen Tutorial auch
http://www.python.org/doc/current/tutor ... -variables

[BlackJack]

@frabron: Man muss ja nicht alles glauben was in offiziellen Dokumenten steht.

Fakt ist, dass das in Python von den allermeisten Leuten nicht benutzt wird, und nach Meinung dieser Leute auch nicht benutzt werden sollte. Weil es einfach nicht zur Philosophie von Python passt. Ein einfacher Unterstrich sollte genügen um anderen zu signalisieren, dass es sich um Interna handelt, die man nur anfassen sollte, wenn man weiss was man da tut.

Wer sich daran nicht hält und auf die Nase fällt, hat Pech gehabt. Wer sich daran nicht halten *will*, den hält auch der doppelte Unterstrich nicht auf. Damit ist also nichts gewonnen.

[frabron]

RIchtig, ich bin auch froh, dass ich die private, protected, public und static von PHP los bin.

Doch war die Aussage von Leonidas "so" nicht richtig, es gibt ja genug Belege, dass es private mit den zwei Unterstrichen doch gibt. Da wollte ich nur drauf hinweisen. Und wenn man sich als Einsteiger nicht mal auf die offizielle Doku verlassen kann, worauf dann? Man bekommt es zwar hier flott gesagt, aber man bleibt ja (gerade als Umsteiger) gerne bei dem, was man kennt -> Faulheit siegt

Dann sollte man lieber sagen, es gibt zwar private, aber die Verwendung entspricht nicht dem guten Python Stil. Damit ist dann auch alles gesagt.

So, und nun weiter hier im Klappentext

[Leonidas]

Dann sollte man lieber sagen, es gibt zwar private, aber die Verwendung entspricht nicht dem guten Python Stil.

Nein, ich würde trotzdem nicht sagen, dass es private gibt, denn das was du in Python als private bezeichnest ist Name Mangling und nicht mit dem private-Mechanismen von anderen Sprachen vergleichbar.

[frabron]

Ich bezeichne gar nix als private, das steht so in einigen Texten zu Python. Ich weiss leider auch nicht so recht, was name mangling ist, deshalb kann ich mangels Wissen ( haha, Wortspiel ) auch nicht mitreden. Selbst das Pythonbeispiel zu name mangling auf der (en)Wikipedia hilft mir nicht wirklich weiter.

Das Wörterbuch spuckt nur lustige Sachen aus: kalandrieren, mangeln, verstümmeln, wringen, zerfleischen. Klingt ziemlich blutig

Ich glaube, das Thema verlässt deutlich meinen Erfahrungshorizont, da halte ich es lieber mit Dieter Nuhr.

Jedenfalls ist aus der durchaus gängigen Literatur für mich (und wohl auch andere) der Unterschied zwischen ProgrammierspracheX/private und Python/private nicht so recht nachzuvollziehen. Auch wenn das offizielle Handbuch von limitierter Unterstützung schreibt, ist der Unterschied nicht wirklich klar für so Noobs wie mich z.B.

[BlackJack]

Mit ``private`` ist normalerweise ein Zugriffsschutz gemeint, d.h. die Implementierung lässt einen nicht ohne deutliche Verrenkungen oder unsaubere Tricks auf solche Attribute zugreifen. Bei Python wird dagegen nur der Klassenname mit in den Attributnamen eingebaut, d.h. diese nicht wirklich "privaten" Attribute sind von ausserhalb einfach nur unter einem anderen Namen zugänglich.

[lunar]

Im offiziellen Tutorial ist von echten privaten Variablen nirgendwo die Rede, sondern lediglich von "limited support for class-private identifiers". Der darauffolgende Absatz setzt "private" auch gleich in Anführungszeichen und klärt darüber auf, dass dieses Mittel allenfalls der Vermeidung von Namenskonflikten dient, nicht aber echtem Zugriffsschutz, da man bei entsprechender Absicht durchaus auf derartige Namen zugreifen kann.

Im Übrigen erklärt gleich der zweite Satz dieses Abschnitts im Tutorial anhand eines Beispiels, was "Name Mangeling" bedeutet und wie es aussieht. Du solltest die Texte, die du anführst, auch selbst lesen

[frabron]

Hey, das kann ich ja so nun nicht stehen lassen. Ich lese schon die Texte, die ich verlinke !

Trotzdem liest sich einiges nach einer Nacht anders als in der Hitze des Arbeitstages. Auch wenn sich das Konzept in Python anders anhört, finde ich den Aufwand nur geringfügig geringer als z.B. in PHP auf private Eigenschaften zuzugreifen. Ich kann natürlich nur vergleichen, was ich kenne. Und das ist bisher an objektorientierten Sprachen PHP (jaja, ich weiss), Python und Javascript. Wenn ich denn in PHP dringend auf eine private Eigenschaft einer Klasse zugreifen müsste, muss man die Klasse ja auch nur um eine Getter-Funktion erweitern.

Letztendlich dient die Eigenschaft 'private' ja auch nur dem Programmierer, der die Klasse verwendet, zu sagen, dass er die Finger vom direkten Zugriff auf die Eigenschaft lassen soll, egal in welcher Sprache. Und mir reicht es da schon, wenn

Code: Alles auswählen

class MangleMe(object):
    def __init__(self):
        self.__mangle = 'Pfoten weg'

print mm.__mangle
print MangleMe.__mangle
print getattr(mm, '__mangle')

einen AttributeError wirft. Denn jede Methode zur Umgehung des Zugriffschutzes macht dem Programmierer doch bewusst, was er da treibt und dann sollte man sich der Konsequenzen bewusst sein.

Wenn nun ein Anfänger wie Bastil (und ich) von private schreiben, verwirren die Einwände wie "es gibt kein private in Python" mehr als das sie helfen, auch wenn aus Sicht von erfahrenen Programmieren Welten zwischen private und private liegen können. Anfänger lesen nun mal Anfängerliteratur, und wird durchaus von privaten Eigenschaften geschrieben, evt. mit dem Zusatz "weniger strikt" als in anderen Programmiersprachen.Der direkte Zugriff darauf wirft auch einen Fehler, alles funktioniert also wie gewollt. Das macht also in den Augen des Anfängers die private Eigenschaft nicht weniger privat als in PHP oder Java oder welche andere Sprache auch immer.

Denn MeinObjekt.__privat ist ja geschützt, ich muss ja schon explizit MeinObjekt._MeinObjekt__privat aufrufen, um darauf zuzugreifen. Ich verstehe den Einwand des geringeren Schutzes und Aufwandes für den Zugriff, dennoch erscheint mir der Einwand "Python hat keine privaten Attribute" für zu harsch geschrieben, bloss weil man es einfach umgehen kann. Das macht aber die Intention für den Gebrauch des Attributs nicht weniger privat als bei anderen Sprachen.

Naja, just my 2 cents

[Leonidas]

Wenn nun ein Anfänger wie Bastil (und ich) von private schreiben, verwirren die Einwände wie "es gibt kein private in Python" mehr als das sie helfen, auch wenn aus Sicht von erfahrenen Programmieren Welten zwischen private und private liegen können. Anfänger lesen nun mal Anfängerliteratur, und wird durchaus von privaten Eigenschaften geschrieben, evt. mit dem Zusatz "weniger strikt" als in anderen Programmiersprachen.

Daher versuchen erfahrene Programmierer den Anfängern die Sachen zu erklären, so dass sie keinen Code schreiben bei dem ein erfahrener Programmierer sich an den Kopf fassen müsste.

Zudem ja die Intention von "Name Mangling" auch gar nicht "private" Attribute sind, sondern Verhinderung von Namenskollisionen. Die es eher selten gibt, daher auch der seltene Gebrauch von Name Mangling.

[lunar]

@fabron
Deine Argumentation ist ziemlicher Unsinn. Klar kann man harten Zugriffsschutz umgehen, indem man einfach die Schnittstelle ändert. Genauso gut kann man auch einfach das "private" durch "public" ersetzen. Damit umgeht man den harten Zugriffsschutz aber nicht, sondern erzeugt einfach ein ungeschütztes Attribut. Trotzdem haben Sprachen wie Java, PHP oder C# einen harten, von der Sprache forcierten Zugriffsschutz.

Python hat das nicht, auch nicht doppelten Unterstrichen. Die dienen wie gesagt nur der Vermeidung von Namenskonflikten. Sie als private Attribute zu missbrauchen, ist schlechter Stil. Implementierungsdetails kennzeichnet man mit einem einfachen Unterstrich.

[frabron]

Daher versuchen erfahrene Programmierer den Anfängern die Sachen zu erklären, so dass sie keinen Code schreiben bei dem ein erfahrener Programmierer sich an den Kopf fassen müsste.

Das an den Kopf fassen lässt sich wohl nicht vermeiden ich bin mir sicher, dass es immer genug Gelegenheiten neben dieser private Diskussion gibt. Ich komme wieder
Aber immerhin gibt mir diese Diskussion ja genug Gelegenheit, mich in dieser Angelegenheit weiterzubilden.

Deine Argumentation ist ziemlicher Unsinn.

Das lasse ich jetzt mal so stehen, denn ich befürchte sehr, dass ich da mangels Wissen nicht argumentativ widersprechen kann.
Das heisst dann also, dass der Kernsatz aus der Dokumentation folgender ist:

Code: Alles auswählen

Name mangling is intended to give classes an easy way to define “private” instance variables and methods, without having to worry about instance variables defined by derived classes, or mucking with instance variables by code outside the class.

und lediglich, wie ihr ja mehrfach geschrieben habt, der Vermeidung von Namenskonflikten dient und nicht der Regulierung des Zugriffes von ausserhalb der Klasse.
Vielleicht ist die Überschrift dieses Abschnittes in der Dokumentation einfach etwas doppeldeutig. Denn dieser Doppeldeutigkeit bin ja nicht nur ich auf dem Leim gegangen ...

[Leonidas]

Ich stimme dir insofern zu, dass die Dokumentation an dieser Stelle ausgebessert werden könnte, damit sie klarer vermittelt was gemeint ist.