Das deutsche Python-Forum

@__blackjack__

Mit automatisierten Testframeworks habe ich leider bisher nur sehr wenig Erfahrung, da das in Delphi leider sehr umständlich ist und nach fast einhelliger Expertenmeinung nur mittelprächtig funktioniert. Allerdings gibt's ja zum Glück je nach Kreativität des Entwicklers noch andere Möglichkeiten (auch in Delphi) automatisiert zu testen. Man muss dann z.B. Abstriche bei der Testtiefe machen.
Es hat daher einen Moment gedauert, bis ich herausgefunden habe, wie die beiden Varianten Untitest und Pytest anzusteuern sind. (Für pytest musste ich in PyCharm in den Settings den Default TestRunner ändern. Ich hoffe, dass das die korrekte Vorgehensweise ist)

Nun verstehe ich auch, warum Du in pytest einen Vorteil siehst. Das Protokoll ist imho auch übersichtlicher.

Ich konnte zwar erkennen, zu welchem Output die folgende Zeile führt. Und das fand ich sehr charmant, weil es auf den ersten Blick so aussieht, als könnte das für generische datengetriebene Tests einen Vorteil bieten.
Ist meine Annahme korrekt?
Den @-"Operator" muss ich mir allerdings noch näher anschauen. Mir ist noch nicht ganz klar, wo der Unterschied zwischen Fixtures und Decorator ist. (Muss ich googeln. Mühsam ernährt sich das Eichhörnchen )

Für das Spielzeug-Beispiel habe noch folgendes importiert, damit es (bei mir) laufähig war: Das waren Vorschläge von PyCharm. Allerdings habe ich keine Ahnung, ob dies sinnvolle Vorschläge sind. Mein Bauchgefühl sagt: Nein.

Leider bekomme ich ohne diese Importe folgende Fehlermeldung Ich vermute aber (unabhängig davon ob der Code läuft oder nicht) muss ich zunächst Fixtures verstehen.

Vielen lieben Dank für Deine wirklich sehr hilfreichen Infos. (Dank Deiner Infos oben habe ich direkt gelernt, wie man in Python automatisierte Tests ansteuert! )

LG

@Buchfink: Ein Dekorator ist einfach nur ein aufrufbares Objekt, das mit einer Funktion oder Klasse aufgerufen wird: ist exakt das gleiche wie Das hat also erstmal nichts mit Fixtures zu tun. Pytest benutzt einfach nur die Dekorator-Syntax, um Fixtures zu registrieren.

@narpfel

vielen lieben Dank für die Erläuterung.

Auf den ersten Blick sieht es aus wie ein Funktionszeiger.
Allerdings bin ich mir unsicher, ob das in Python der richtige Begriff ist. Ich muss da aufpassen, dass ich nicht Konzepte blind übertrage, weil eine Mustererkennung in meinem Hirn "anschlägt".
Gerne könnt ihr mich hier korrigieren, falls das eine falsche Annahme ist.

Ich habe die Dekoratoren mal im Rahmen eines Flask-Tutorials gesehen. Da wurde das - wenn ich es richtig in Erinnerung habe - für das Routing eingesetzt.
Allerdings verstehe ich Dinge immer am besten, wenn ich es selbst mal aktiv verwende.

@Buchfink: In Python gibt es keine Zeiger. Alles, was man an einen Namen binden kann, ist ein Objekt. Z. B. ist `42` ein Objekt vom Typ `int`, `True` ist ein Objekt vom Typ `bool` und nach ist `bar` ein Objekt vom Typ `function`. Bei würdest du ja auch nicht von einem Int-Zeiger sprechen, warum also „Funktionszeiger“?

@narpfel, @__blackjack__
ich habe nun diese Erklärung für Fixtures gefunden:
https://www.tutorialspoint.com/pytest/p ... xtures.htm

Es klingt ein wenig so, als wäre "Fixtures" ein pytest-spezifischer Begriff. Wenn ich mir in google die Trefferliste für "fixtures python " anschaue, sieht das zumindest auf den ersten Blick so aus. Ich bin mir allerdings nicht sicher, ob das wirklich stimmt.

LG

Fixtures sind ein allgemeiner Begriff für Dinge, die man in Tests gerne vorbereitet hat für den eigentlichen Test. Also zb gemockte Datenbanken oder andere Objekte, mit denen der Code unter Test arbeiten soll.

@narpfel

In Python gibt es keine Zeiger

Das meinte ich, als ich schrieb, dass ich evtl. Konzepte aus mir bekannten Sprachen übertrage, die in Python _so_ aber nicht greifen oder anders heißen. Da schlägt einfach manchmal die Mustererkennung im Hirn (falsch) zu.

würdest du ja auch nicht von einem Int-Zeiger sprechen, warum also „Funktionszeiger“?

hm... Ist ein Objekt in Python keine Speicheradresse? Bzw. muss man in Python wissen, was auf Heap und Stack liegt? Oder liegt alles auf dem Heap weil alles Objekte sind? Oder bin ich mit diesen Fragen total auf dem Holzweg?

Entschuldigt vielmals - ich müsste all diese Fragen eigentlich erst googeln, bevor ich diese hier so unqualifiziert hier rein puste. Ich hoffe, ihr seht es mir nach.

@__deets__
dankeschön für die Erläuterung.

Bin leider etwas unerfahren, was Testframeworks anbelangt. Ich weiß nur, dass ich ohne automatisierte Tests nicht mehr arbeiten möchte. Wenn das in Python so komfortabel geht, ist das absolut klasse

@Buchfink: „Speicheradresse“, „Heap“ und „Stack“ sind Begriffe, die Python nicht kennt. Und mit „Python“ meine ich die Sprache, nicht irgendeine Implementierung der Sprache. Ein Objekt in Python-der-Sprache ist ein abstraktes Ding, das man an einen (oder mehrere) Namen binden kann, das Attribute hat und auf dem man Methoden aufrufen kann. Wie das implementiert ist, ist in Python-der-Sprache nicht spezifiziert und damit für den Programmierer in erster (und wahrscheinlich auch zweiter) Näherung nicht wichtig.

Buchfink hat geschrieben: Donnerstag 21. Oktober 2021, 21:15 Ist ein Objekt in Python keine Speicheradresse? Bzw. muss man in Python wissen, was auf Heap und Stack liegt? Oder liegt alles auf dem Heap weil alles Objekte sind? Oder bin ich mit diesen Fragen total auf dem Holzweg?

Diese Fragen machen deswegen im Kontext von Python-der-Sprache keinen Sinn, weil die Dinge, nach denen du fragst, auf dem Abstraktionsniveau einfach nicht existieren. Analogie: „Wie schwer ist 42?“ (Python-die-Sprache) vs. „Wie schwer sind diese 42 Steine, die hier vor mir liegen?“ (Konkrete Implementierung von Python-der-Sprache).

@narpfel
dankeschön für Deine hilfreichen Erläuterungen.

Python ist für mich ein bisschen wie "eine andere Welt" Aber es ist eine tolle Welt!

@Buchfink: Wie man das jetzt speziell in PyCharm verwendet weiss ich nicht. Ich schreibe mit einem normalen Editor und lasse Tests im Terminal laufen. Also `pytest` als Programm ausführen, mit dem was getestet werden soll als Argument und ggf. noch Optionen um Tests auf bestimmte einzelne Tests oder Gruppen von Tests einzuschränken, und beispielsweise so etwas wie Doctests auch gleich auszuführen.

Für `unittest`-Tests verwende ich auch `pytest`, weil das wie gesagt auch damit klar kommt, und sofern sich bei `unittest` da nichts geändert hat, sind die Ausgaben von `pytest` um einiges besser, weil das einiges an Mühe darauf verwendet auch den jeweiligen Ausdruck zu verstehen der fehlgeschlagen ist, und welche Werte die beteiligen Variablen hatten, und dann auch versucht ein sinnvolles ”diff” zwischen dem Ergebnis und dem erwarteten Wert anzuzeigen.

Die Klassen `Document` und `Paragraph` sind keine konkreten, das war nur als Beispiel um da irgendwas zu haben, unter dem man sich was vorstellen kann.

Zu „test fixture“ allgemein gibt es eine Wikipedia-Seite: https://en.wikipedia.org/wiki/Test_fixture

Das ist sogar so allgemein, dass der Begriff nicht auf Software-Entwicklung beschränkt ist.

@__blackjack__
Ich nutze je nach dem an welchem Rechner ich bin und was gerade zweckdienlich ist, JupyterNotebooks /JupyterLab , PyCharm oder VSCode.
So lerne ich auch gleich die verschiedenen IDEs und deren Vor- und Nachteile.
Im Moment bin ich noch unentschlossen, was mir besser gefällt - aber PyCharm nutze ich deutlich öfter. (Es ist ja alles besser wie das, was von Embarcadero kommt...)

Die JupyterNotebooks finde ich deshalb sehr praktisch, weil man damit auch schnell mal was ausprobieren kann. Es gibt noch eine Reihe weitere Vorteile, die kennst Du aber bestimmt alle. (Manchmal wenn es die Zeit zulässt, versuche ich Probleme, die hier diskutiert werden, zu verstehen und die Lösung nachzuvollziehen. Dabei lerne ich auch ziemlich viel, habe ich festgestellt. Besonders wenn hier verschiedene Lösungen gegeneinander abgewogen werden, finde ich die Diskussion sehr spannend und lehrreich. Dies soll an dieser Stelle auch mal gesagt sein)

und dann auch versucht ein sinnvolles ”diff” zwischen dem Ergebnis und dem erwarteten Wert anzuzeigen.

ja, genau das war mir auch aufgefallen. Und gute Fehlermeldungen sind oft Gold wert.
(Z.B. bei den integrierten automatisierten Tests von Postman sind die Fehlermeldungen imho auch ziemlich gut, aber das nur am Rande.)

Die Klassen `Document` und `Paragraph` sind keine konkreten, das war nur als Beispiel um da irgendwas zu haben, unter dem man sich was vorstellen kann.

ja, das habe ich gestern Abend dann auch irgendwann vermutet. In geistiger Umnachtung habe ich da gestern wohl einigen Stuß geschrieben
Und vielen Dank für den Wikipedia-Artikel. Der war sehr aufschlussreich.

Nachtrag zu meinem Geschreibsel von gestern:
Leider habe ich oft nur am Wochenende länger Zeit, um mich neuen Themen ausführlicher zu widmen. Da sich aber viele nette Menschen hier so viel Mühe geben, mir auch zeitnah Sachen zu erklären, möchte ich immer aber wenigstens kurz darlegen, wie mein "aktueller Wissensstand" dazu ist und wo noch Fragen in meinem Hirn herumschwirren. Denn meist ist das eine regelrechte Fragenkasskade, die dann auf Basis des neuen Inputs in meinem Kopf entsteht.
Und ich möchte keinesfalls den Eindruck erwecken, dass ich die Informationen, die ihr mir hier so freundlich zukommen lasst "versacken" lasse.
Dies nur als kleine Erklärung, warum ich manchmal unqualifizierte Fragen schreibe und direkt dazu schreibe, dass ich das noch googeln muss.
Ich habe den Anspruch, meine Fragen immer so zu formulieren, dass ich nicht "die Entwickler-Innung blamiere" - aber ich glaube manchmal geht das daneben

Morgen ist Samstag. Ganz viel Zeit um mich nochmal ausführlicher mit den ganzen "Dunder"-Methoden zu befassen. Jedenfalls ist das mein Vorhaben für dieses Wochenende.
Dann kommen hoffentlich auch qualifizierte/interessante Fragen von mir.

LG

Hallo zusammen,

bei meinen Recherchen bin ich auf folgenden Link gestoßen:
https://nbviewer.org/github/rasbt/pytho ... vate_class

Ich dachte ggf. wäre es sinnvoller, das "Pferd mal von hinten aufzuzäumen" und zu schauen, was es alles sonst so an populären Irrtümern in Python gibt (bevor ich in die nächste Falle latsche)
Sprich: "Wissensdefault" einfach rumdrehen und mal einen Blick auf die Besonderheiten werfen.

Passend zu diesem Thread habe ich die oben stehende Erklärung gefunden. So wie ich das nun mit den Underscores verstanden habe, ist die Erklärung dort nicht falsch. Aber durchaus nicht ganz so klar, wie das, was ich aus dem Beitrag von @__blackjack__ herausgelesen habe. Denn das klingt bei Herrn Raschke so, als wäre das durchaus eine gängige Methode "ein bisschen Privatheit" zu bekommen. Der "Missbrauchscharakter" kommt da imho nicht so ganz heraus.

Was ist denn Eure fachliche Meinung zu dem Artikel über "private"?

Lieben Dank schon mal für Eure Einschätzung.

Hintergrund meiner Frage ist, dass ich nur bedingt einschätzen kann, inwieweit der Rest dort fundiert ist. Einerseits geht es stellenweise sehr in die Tiefe (was ich sehr interessant finde) aber andererseits wird viel Wissen vorausgesetzt (was ich noch nicht habe).
Es werden dort halt viele Fragen beantwortet, die ich mir auch schon gestellt habe.
Im Moment ist die "Private"-Thematik für mich daher bisschen ein Lackmus-Test, um zu entscheiden, ob ich eine Quelle näher ansehe.

Am Rande
Die restlichen Sachen, die dort aufgeführt sind, habe ich nur grob überflogen. Einiges konnte ich verstehen, jedoch nicht alles. Ich habe noch viel vor mir

Sorry wenn der Eindruck entsteht, dass ich mich da ein bisschen "dran festbeiße", aber mir liegt es daran, wirklich zu verstehen, was ich tue. Alles andere ist ja immer "gefährliches Halbwissen".

LG

Buchfink hat geschrieben: Samstag 23. Oktober 2021, 12:39 Was ist denn Eure fachliche Meinung zu dem Artikel über "private"?

Klingt prinzipiell OK. Ich würde allerdings den Begriff "private" durch "for internal use" ersetzen.

Da kommt dann der Unterchied zu einem "private" wie es z.B. in C++ verwendet wird zum Vorschein. Ich kann so ein Attribut/eine Methode als Entwickler verwenden, wenn ich davon überzeugt bin, dass mir das Vorteile welcher Art auch immer bringt - und das kann ab und zu tatsächlich sehr praktisch sein. Ich muss mir nur darüber im Klaren sein, dass es keine Garantie dafür gibt, dass besagtes Attribut/Methode in der nächsten Version der Bibliothek noch vorhanden ist und/oder das gleiche tut.

@Buchfink,

ich weiß nicht ob ich mir anmaßen kann eine fachlich versierte Einschätzung zu geben.
Es ist gut, dass der Autor nicht versucht, public und private auf Python anzuwenden, sondern eigentlich erklärt, dass es diese Zugriffsbeschränkung in Python eigentlich gar nicht gibt. Noch besser wäre es gewesen, den Artikel zu public / private gar nicht zu schreiben
Es ist einfach kein Thema in Python. Ich persönlich habe es auch nie vermisst, seit dem ich in Python programmiere. Das ist so als würdest du mit einem Elektroauto an einer Tankstelle vorbeifahren.

Ich habe den Rest nur überflogen. Es sind sicher einige gute und für Python wichtige und relevante Themen dabei. Erfrischend finde ich, dass es nicht mit "Hallo Welt" anfängt, sondern an eher erfahrene Programmierer gerichtet ist.
Persönlich würde ich offizielle Python-Veröffentlichungen immer als Maßstab nehmen, also das Python Tutorial und die Dokumentation. Dazu kann man noch einen Blick in die PEP werfen um weitere Hintergrundinformationen zu bekommen.
Ich weiß es nicht genau, aber ich bin mir ziemlich sicher, dass diese Dokumente von sehr erfahrenen Python-Entwicklern geprüft bzw. geschrieben werden.
Alles andere ist oft aus der Sichtweise von Einzelnen geschrieben. Dann schaust du halt durch deren Brille.

@/me

danke - ja da hast Du Recht. Du bringst das, was mich gestört hat, sehr gut auf den Punkt. Denn "private" scheint mir in diesem Kontext eine falsche Vokabel zu sein.

Das andere, was mich irritiert hat, war dann, dass da auch (aber etwas verklausuliert) der Hinweis kam, dann die zwei Underscores zu nutzen. Allerdings wurde dort zumindest drauf hingewiesen, dass es für was anderes gedacht ist und dass es keinen "Schutz" bietet. Immerhin.
Ich glaube aber, dass ich das ohne die Erklärung von Euch hier gar nicht herausgelesen hätte...

Nun ja, ich werde mir dann mal die anderen Sachen anschauen, die dort aufgelistet sind

@rogerb

Erfrischend finde ich, dass es nicht mit "Hallo Welt" anfängt, sondern an eher erfahrene Programmierer gerichtet ist.

ja, das habe ich auch so gesehen.
Wenn ich bei den Tutorials bei 0 anfange, dann kommt immer sehr viel Basiswissen. Klassen kenne ich schon. Vererbung auch etc. Es ist daher immer bisschen schwer zu sagen, welchen Teil eines Tutorials kann ich überspringen und wo werden ggf. pythonische Besonderheiten erklärt.

Im Moment versuche ich mich wie auch von Dir vorgeschlagen primär an den offiziellen Quellen zu orientieren. Allerdings verstehe ich dort nicht immer alles, weshalb ich dann immer erst mal google anwerfe und schaue, ob ich darüber vielleicht erst mal meine Fragen soweit klären kann (so bin ich auch über den Link oben gestolpert).

Lieben Dank für Deine Einschätzung!

@Buchfink,

das stimmt, die offiziellen Quellen, sind sicher eher für Pythonentwickler als Referenz zum Nachschlagen gedacht und gehen von Vorwissen aus.
Ich vertraue auch noch auf die kostenfreie Version dieser Seite:
https://realpython.com/
Die Artikel gehen auch ins Detail. Der jeweilige Autor stellt sich unter dem Artikel kurz vor und viele Artikel werden auch von mehreren Autoren zusammen geschrieben.

Diese Seite ist eine der schlechtesten die ich je gesehen habe (nur mal so zum Vergleich und als Vorwarnung)
https://www.geeksforgeeks.org/

@rogerb

danke für den Tipp!
auf geeksforgeeks bin ich auch noch nie fündig geworden. (zu viel Rauschen glaube ich....)
In Delphi muss ich oft mit Libs arbeiten, zu denen es gar keine Doku gibt. Und da helfe ich mir, indem ich einfach in die Lib hineindebugge und einfach gucke, wie das, was ich brauche funktioniert. (Streng genommen ist ja eigentlich nur der Quellcode die Primärquelle)

In Python scheint das unüblich zu sein, vermute ich?

Buchfink hat geschrieben: Samstag 23. Oktober 2021, 18:30 In Python scheint das unüblich zu sein, vermute ich?

Keineswegs. Auch wenn Libraries gut Dokumentiert sind, kann sich eine Blick in die Sources lohnen und Fragen beantworten, die für einen persönlich in der Dokumentation offen geblieben sind.