Alfons Mittelmeyer's Wundersame Welt
@Alfons Mittelmeyer: ``import`` ist kein Unsinn sondern der von der Sprache vorgesehene Weg Module zu importieren. Das als Sicherheitsrisiko und Unsinn zu bezeichnen und stattdessen `compile()` und `exec` und eine eigene Begriffswelt mit ”Skripten” die keine Module sind zu schaffen zeugt von Unverständnis. Und Du trollst, weil ich Dir unterstelle das nicht wirklich *so* dämlich sein kannst wie Deine ”Argumente”. Und trollen nervt. Lass das bitte sein.
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@BlackJack Natürlich ist import kein Unsinn, wenn man import benutzt, um Module zu importieren. Aber hier geht es um Scriptausführung. Wenn man import aufruft und zwar zum ersten Mal für ein Modul, dann findet eine Initialisierung verbunden mit Funktionsausführung statt. Und genau nur diese Funktionsausführung wird für die Ausführung eines Scripts benötigt. Wenn man dafür einen import eines Moduls benützt, ist nach dem Aufruf von Import das Script ausgeführt worden und damit das Modul verbraucht und nutzlos geworden, wenngleich es noch nicht Garbage ist. Wenn es sich etwa um ein Toplevel Window handelt und der User betätigt dann einen Close Button, dann wird das Toplevel Window gelöscht und jetzt bleibt dann Garbage übrig. Vom Speicherverbrauch vielleicht nicht so schlimm. Aber Garbage, der unnötigerweise dazu auch noch global definiert ist. Zur Programmbeendigung könnte man ihn ja verwenden. Wenn man da jetzt eine Callbackfunktion aufruft, die dann ungültige Referenzen auf gelöschte Widgets hat, ja dann gäbe es einen Programmabsturz verbunden mit Programmbeendigung.
@Alfons Mittelmeyer: Skripte sind Module. Also gibt es schonmal den Unterschied zwischen beidem nicht den Du schon wieder versuchst herbeizureden. Das hatten wir schon mal.
Und mit dem was Du da als Garbage bezeichnist bist auch wieder nur Du der einzige der da ein Problem sieht. Es ist schlicht so vorgesehen. Wenn Du das nicht haben willst ist das Deine Sache, aber versuch doch bitte nicht ständig anderen ungefragt und unpassend Deine extrem abweichende Weltsicht überhelfen zu wollen.
Und mit dem was Du da als Garbage bezeichnist bist auch wieder nur Du der einzige der da ein Problem sieht. Es ist schlicht so vorgesehen. Wenn Du das nicht haben willst ist das Deine Sache, aber versuch doch bitte nicht ständig anderen ungefragt und unpassend Deine extrem abweichende Weltsicht überhelfen zu wollen.
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@BlackJack, Du kannst natürlich den Standpunkt vertreten, dass alles, was man als Modul importieren kann, auch ein Modul ist. Und wenn Du folgendes hineinschreibst:dann kannst Du das sicherlich importieren. Aber das ist ein ziemlich sinnloses Modul. Und solche sinnlosen Module habe ich keine Lust zu erzeugen.
Wenn Du das vier Leerzeichen einrückst und dann eine Funktion drum rummachst oder daraus eine Klasse machst, erst dann wird es ein sinnvolles Modul.Ein Modul soll nämlich eine Library sein und aufrufbare Funktionen oder Klassen haben. Printanweisungen allein ohne etwas Aufrufbares kann man in ein Script schreiben. Und das Main Script heißt Mainscript und auch nicht Main Modul. Und da gibt es auch noch einen Unterschied zu einem Modul. Es ist nämlich nicht in __pycache__.
Und was der Lauf der Dinge ist? Ein statische GUI hat man bis zum Programmende. Da macht es durchaus viel Sinn, diese als Modul zu importieren. Dynamische variable GUIs unlimited dagegen sollten nach Schließen automatisch entsorgt werden. Und dafür sollte man dem Garbage Collector die Gelegenheit geben und nicht mit aller Gewalt das verhindern wollen.
Code: Alles auswählen
print('This is a Module')
Wenn Du das vier Leerzeichen einrückst und dann eine Funktion drum rummachst oder daraus eine Klasse machst, erst dann wird es ein sinnvolles Modul.Ein Modul soll nämlich eine Library sein und aufrufbare Funktionen oder Klassen haben. Printanweisungen allein ohne etwas Aufrufbares kann man in ein Script schreiben. Und das Main Script heißt Mainscript und auch nicht Main Modul. Und da gibt es auch noch einen Unterschied zu einem Modul. Es ist nämlich nicht in __pycache__.
Und was der Lauf der Dinge ist? Ein statische GUI hat man bis zum Programmende. Da macht es durchaus viel Sinn, diese als Modul zu importieren. Dynamische variable GUIs unlimited dagegen sollten nach Schließen automatisch entsorgt werden. Und dafür sollte man dem Garbage Collector die Gelegenheit geben und nicht mit aller Gewalt das verhindern wollen.
Zuletzt geändert von Alfons Mittelmeyer am Donnerstag 5. November 2015, 15:49, insgesamt 1-mal geändert.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Was sollte es denn auch sonst sein? Ein Modul ist einfach die kleinste Organisationseinheit für beliebigen Python-Code. Kann man auch nachlesen... von "Scripten" geschweige denn von einem Unterschied zwischen beiden findet man da nichts - wie auch :K Das ist ja einfach nur eine gehaltlose These von Dir...Alfons Mittelmeyer hat geschrieben:@BlackJack, Du kannst natürlich den Standpunkt vertreten, dass alles, was man als Modul importieren kann, auch ein Modul ist.
Meinst Du erzeugen oder nutzen? Erzeugen musst Du es ja nicht; schreib halt nicht so etwas sinnloses, fertig Und Benutzen muss man das auch nicht - wenn mir ein Modul nicht gefällt, nutze ich es einfach nicht. Also alles kein ProblemAlfons Mittelmeyer hat geschrieben: Und wenn Du folgendes hineinschreibst:dann kannst Du das sicherlich importieren. Aber das ist ein ziemlich sinnloses Modul. Und solche sinnlosen Module habe ich keine Lust zu erzeugen.Code: Alles auswählen
print('This is a Module')
Nur weil ein Modul aus *einer* Python-Anweisung oder Funktionsaufruf bestehen kann, heißt das doch nicht, dass man das auch so nutzen sollte! Es braucht einfach keinen "Workaround" für derartige Module, weil diese in der Praxis nicht vorkommen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@BlackJack Was in der Praxis vorkommt ist aber, dass ein Script andere Scripts zum Aufbau einer GUI Seite nachlädt. Und wenn das dann insgesamt 50 Scripts sind, habe ich nicht viel Lust, daraus dann 50 Module zu erzeugen. Außerdem habe ich keine Lust eine href->Modul Verwaltung zu erstellen, damit man weiß, welche Module man schon hat. Abgesehen davon ergibt sich dann auch das Problem, welche davon sind noch aktuell.
Wenn einer dann für so eine GUI Seite den Refresh Button drückt, soll ich dann einfach nochmals 50 Module erzeugen? Nein Danke, so einen Murks mache ich einfach nicht mit, nur weil da einige der Ansicht sind, dass man compile und exec nicht benützen und stattdessen import benützen soll.
Wenn einer bei compile und exec ein rotes Tuch vor Augen hat, dann ist er keinesfalls gezwungen, GuiDesigner Scripte mit load_script - noch nicht auf GitHub - zu laden. Er kann es auch mit 'import' tun, verzichtet dann aber auf die einfache Möglichkeit, eigene Klassen zu verwenden. Soll er die dann eben selbst eintragen, wenn er eigene Klassen haben will.
Wenn einer dann für so eine GUI Seite den Refresh Button drückt, soll ich dann einfach nochmals 50 Module erzeugen? Nein Danke, so einen Murks mache ich einfach nicht mit, nur weil da einige der Ansicht sind, dass man compile und exec nicht benützen und stattdessen import benützen soll.
Wenn einer bei compile und exec ein rotes Tuch vor Augen hat, dann ist er keinesfalls gezwungen, GuiDesigner Scripte mit load_script - noch nicht auf GitHub - zu laden. Er kann es auch mit 'import' tun, verzichtet dann aber auf die einfache Möglichkeit, eigene Klassen zu verwenden. Soll er die dann eben selbst eintragen, wenn er eigene Klassen haben will.
@Alfons Mittelmeyer: Du hast da schon wieder diesen komischen Skriptbegriff der keinen Sinn ergibt. 50 Skripte und 50 Module sind das gleiche weil Skripte nun mal Module sind. Was Du da mit ”erzeugen” meinst versteht auch wieder keiner ausser Dir. Hast Du da schon wieder das erzeugen von Quelltext zur Laufzeit im Kopf? Das macht in der Praxis ja auch wieder niemand ausser Dir. Wir meinen mit Praxis das was man normalerweise als Python-Programmierer macht — nicht Deine komischen Irrwege. Wenn jemand einen Refresh-Button drückt, dann sollte Code ablaufen der die UI entsprechend aktualisiert. Dazu braucht man weder `compile()` noch `exec` noch ``import``. Jedenfalls nicht wenn man normalen Code schreibt und nicht irgendwelche abwegigen Sachen macht. Die bei Dir ja auch nur Hirngespinste sind, denn Du streust hier immer wieder die Idee ein Module/Code wie Webseiten laden zu wollen, was auch niemand macht ausser Dir. Ja noch nicht mal Du, denn diese unendlich vielen „GUI-Seiten“ gibt's ja auch nur in Deinem Kopf.
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@BlackJack Script und Modul ist nicht dasselbe. Die Definition, auf die Du verwiesen hattest, besagt:
Irgendwie scheinst Du das einfach nicht zu kapieren. Und Quellkode zur Laufzeit generieren, davon war nicht die Rede. Mit Modul erzeugen, war importieren gemeint. Lediglich der Modulname müßte dabei dynamisch generiert werden, was aber kein allzu großes Problem darstellt. Und mit GUI aktualisieren bei Refresh Button Druck. Ja wenn die GUI so definiert ist, dass dabei insgesamt 50 Teile geladen werden, dann bleibt wohl nichts anderes übrig, als bei Refresh die wieder neu zu laden. Was soll man denn anderes tun, wenn nichts anderes darüber bekannt ist? Quelltextanalyse, ob es auch anders geht? Nein danke. Und die vielen GUI Seiten, Hirngespinste? Der GUI Designer besteht zur Zeit aus 57 Scripten, von denen nicht ganz 40 gleich geladen werden, und an die 20 jedes Mal wieder neu hinzugeladen werden, wenn man die entsprechenden Buttons, Labels oder Menüpunkte drückt. Und die LinkLabels und LinkButtons entsprechen <href> mit Verzweigungsmöglichkeiten ohne Einschränkung. Allerdings sollte ich noch eine Browse History machen, damit man auch einen Back Button benutzen könnte.
Das Mainscript, welches Bestandteil des Top-Level-Script Environments ist, ist demnach kein Modul, da es nicht importiert ist. Zum Top-Level-Script Environment gehören auch Programmzeilen, die man direkt eintippen kann. Auch diese Programmzeilen sind keine Module, oder siehst Du das anders?module
An object that serves as an organizational unit of Python code. Modules have a namespace containing arbitrary Python objects. Modules are loaded into Python by the process of importing.
Irgendwie scheinst Du das einfach nicht zu kapieren. Und Quellkode zur Laufzeit generieren, davon war nicht die Rede. Mit Modul erzeugen, war importieren gemeint. Lediglich der Modulname müßte dabei dynamisch generiert werden, was aber kein allzu großes Problem darstellt. Und mit GUI aktualisieren bei Refresh Button Druck. Ja wenn die GUI so definiert ist, dass dabei insgesamt 50 Teile geladen werden, dann bleibt wohl nichts anderes übrig, als bei Refresh die wieder neu zu laden. Was soll man denn anderes tun, wenn nichts anderes darüber bekannt ist? Quelltextanalyse, ob es auch anders geht? Nein danke. Und die vielen GUI Seiten, Hirngespinste? Der GUI Designer besteht zur Zeit aus 57 Scripten, von denen nicht ganz 40 gleich geladen werden, und an die 20 jedes Mal wieder neu hinzugeladen werden, wenn man die entsprechenden Buttons, Labels oder Menüpunkte drückt. Und die LinkLabels und LinkButtons entsprechen <href> mit Verzweigungsmöglichkeiten ohne Einschränkung. Allerdings sollte ich noch eine Browse History machen, damit man auch einen Back Button benutzen könnte.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Diese Begriffe sind ja schon wieder Deine eigenen! Nutze doch einfach die gängige Nomenklatur! "Top-Level-Script Environments" und "Mainscript" kapiert hier außer Dir niemand - genau deswegen gibt es ja Definitionen.Alfons Mittelmeyer hat geschrieben:Das Mainscript, welches Bestandteil des Top-Level-Script Environments ist, ist demnach kein Modul, da es nicht importiert ist.
Im übrigen ist Deine Schlussfolgerung unzulässig. Nur weil der Import-Mechanismus des Moduls mit dem Programmeinstiegspunkt vor Dir versteckt ist und durch den Interpreter vorgenommen wird, heißt das noch lange nicht, dass es nicht importiert wird. Und selbst wenn dieser eine spezielle Vorgang aus der Reihe tanzte, wäre es dennoch ein Modul, denn ich kann jedes Modul in einem anderen importieren
Da wir nicht wissen, was das eigentlich meint, sehen wir das gar nicht! Aber noch einmal: JEDER GÜLTIGE PYTHON AUSDRUCK UND WENN ER NOCH SO TRIVIAL, BANAL ODER UNSINNIG IST, DER IN EINER DATEI STEHT, IST EIN MODUL!Alfons Mittelmeyer hat geschrieben: Zum Top-Level-Script Environment gehören auch Programmzeilen, die man direkt eintippen kann. Auch diese Programmzeilen sind keine Module, oder siehst Du das anders?
Wenn es niemand außer Dir kapiert, kannst Du es entweder nicht vermitteln oder es ergbit keinen Sinn! (Betrachte das als logisches Oder und nicht als XOR! )Alfons Mittelmeyer hat geschrieben: Irgendwie scheinst Du das einfach nicht zu kapieren.
Dann SCHREIB das doch gleich so!!! Niemand denkt beim Begriff "erzeugen" an importieren - ich hoffe Du befolgst das Prinzip der geringsten Überraschung in Deinem Code besser als in der Prosa...Alfons Mittelmeyer hat geschrieben: Mit Modul erzeugen, war importieren gemeint.
Hu, was bedeutet denn wieder "laden"? Ob die Klassen, Funktionen usw. nun in Modulen stehen oder nicht, spielt doch für die Funktion des Programms keine Rolle! Ich kann auch alles in *ein* Modul schreiben. Vermutlich meinst Du, dass Du die Objekte *neu* erzeugen willst. Das ist aber ja vollkommen unabhängig davon, wie ich meinen Code physisch organisiere... Aber wirklich verständlich war Dein Beispiel eh nicht - vielleicht auch wieder, weil man das Problem praktisch so nicht hat, sondern es anders lösen würde als Du?Alfons Mittelmeyer hat geschrieben: Und mit GUI aktualisieren bei Refresh Button Druck. Ja wenn die GUI so definiert ist, dass dabei insgesamt 50 Teile geladen werden, dann bleibt wohl nichts anderes übrig, als bei Refresh die wieder neu zu laden. Was soll man denn anderes tun, wenn nichts anderes darüber bekannt ist? Quelltextanalyse, ob es auch anders geht? Nein danke.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@Hyperion Meine eigener Begriff ist Top Level Environment sicher nicht, denn es ist hier definiert:
Aber mit so einer lausigen Begriffsbildung kommen wir sicherlich nicht weiter, sodaß wir etwas adäquat damit etwas ausdiskutieren können. Jedenfalls liefert 'import' nicht das, was ich brauche, gleich gar nicht, was ich beim GuiDesigner verwende, nämlich abschnittsweise Ausführung.
Weißt Du was das ist? Scripte etwa kann man auch Zeile für Zeile ausführen, sofern da keine Funktions- oder Klassendefinition in die Quere kommt. Aber soweit gehe ich gar nicht. Ich lese einfach Zeile für Zeile aus einem Script ein, bis ich auf eine Markierung für einen Code Block im Script stoße. Und dann führe ich über die eingelesenen Zeilen compile und exec durch. Danach weiß ich, welches Widget das Container Widget ist und stopfe den Inhalt des gefundenenen Code Blocks kurzerhand da hinein. Bei 'Load & Edit' war es das. Bei 'Load & Run' führe ich diesen Code Block außerdem noch mit compile und exec aus. Und dann geht es weiter so, bis dann der nächste Code Block auftaucht oder das Fileende. Nun mag der User die GUI editieren. Er kann auch eine viertausend Zeilen GUI in 50 kleine Abschnitte zerteilen, jedenfalls, wenn er die GUI oder einen Ausschnitt davon abspeichert, der Code Block aus dem Container Widget mit Callback Funktionen und dergleichen wird dann auch mit dazu abgespeichert.
Dann hat man immer GUI und Code gleich zusammen mit dabei. Funktioniert tadellos. Mit einem 'import' geht so etwas aber überhaupt nicht. Da siehst Du mal, was man mit compile und exec anstellen kann, mit import aber nicht.
Leider ist is da ziemlich lausig definiert, denn dabei steht außerdem Modul. An anderer Stelle, auf die BlackJack verwies, steht dass das, was importiert wird, ein Modul ist. Wir haben hier leider eine ziemliche lausige Nomenklatur, bei der nichts wirklich klar definiert ist. Und in Deinem Post schreibst Du jetzt sogar, dass was ich tue, nämlich compile und exec auch importiert wäre. Ja wozu streiten wir uns dann überhaupt? Dann kann ja jeder zufrieden sein, denn ich habe es ja dann doch importiert, oder?28.5. __main__ — Top-level script environment
This module represents the (otherwise anonymous) scope in which the interpreter’s main program executes — commands read either from standard input, from a script file, or from an interactive prompt. It is this environment in which the idiomatic “conditional script” stanza causes a script to run:
if __name__ == "__main__":
main()
Aber mit so einer lausigen Begriffsbildung kommen wir sicherlich nicht weiter, sodaß wir etwas adäquat damit etwas ausdiskutieren können. Jedenfalls liefert 'import' nicht das, was ich brauche, gleich gar nicht, was ich beim GuiDesigner verwende, nämlich abschnittsweise Ausführung.
Weißt Du was das ist? Scripte etwa kann man auch Zeile für Zeile ausführen, sofern da keine Funktions- oder Klassendefinition in die Quere kommt. Aber soweit gehe ich gar nicht. Ich lese einfach Zeile für Zeile aus einem Script ein, bis ich auf eine Markierung für einen Code Block im Script stoße. Und dann führe ich über die eingelesenen Zeilen compile und exec durch. Danach weiß ich, welches Widget das Container Widget ist und stopfe den Inhalt des gefundenenen Code Blocks kurzerhand da hinein. Bei 'Load & Edit' war es das. Bei 'Load & Run' führe ich diesen Code Block außerdem noch mit compile und exec aus. Und dann geht es weiter so, bis dann der nächste Code Block auftaucht oder das Fileende. Nun mag der User die GUI editieren. Er kann auch eine viertausend Zeilen GUI in 50 kleine Abschnitte zerteilen, jedenfalls, wenn er die GUI oder einen Ausschnitt davon abspeichert, der Code Block aus dem Container Widget mit Callback Funktionen und dergleichen wird dann auch mit dazu abgespeichert.
Dann hat man immer GUI und Code gleich zusammen mit dabei. Funktioniert tadellos. Mit einem 'import' geht so etwas aber überhaupt nicht. Da siehst Du mal, was man mit compile und exec anstellen kann, mit import aber nicht.
Da ist nichts lausig definiert. Das vom Interpreter ausgefuehrte Skript wird *implizit* in ein Modul gesteckt, mit dem Namen '__main__'.
Kannst ja mal ueber diesen Ausdruck meditieren:
So. Jetzt hab' ich dem Troll auch mal Futter gegeben
Kannst ja mal ueber diesen Ausdruck meditieren:
Code: Alles auswählen
python -c "import sys; import pprint; pprint.pprint(sys.modules); pprint.pprint(dir(sys.modules['__main__']))"
@Alfons Mittelmeyer: also jetzt hör auf mit dem Quark. Vor zwei Beiträgen schreibst Du noch, dass Module und Skripte was völlig verschiedenes sind und jetzt behauptest Du plötzlich, dass alles ein Modul sei? Du drehst alles so, wie es Dir gefällt, stellst alle anderen als Idioten hin und glaubst, keiner würde Dich durchschauen?
Du schreibst kein Python und willst das auch gar nicht, wenn Du Zeile für Zeile interpretierst, wie es Dir passt, statt das zu nehmen, was Dir Python von Haus aus bietet. Hier gibt es viele, die wollen Python lernen, und nicht Deine neue Sprache, die nicht einmal einen Namen hat. Wenn also jemand Alfonsisch lernen will, dann solltest Du ein Forum aufmachen, und die Leute dort beglücken.
Du schreibst kein Python und willst das auch gar nicht, wenn Du Zeile für Zeile interpretierst, wie es Dir passt, statt das zu nehmen, was Dir Python von Haus aus bietet. Hier gibt es viele, die wollen Python lernen, und nicht Deine neue Sprache, die nicht einmal einen Namen hat. Wenn also jemand Alfonsisch lernen will, dann solltest Du ein Forum aufmachen, und die Leute dort beglücken.
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@Sirius3 Ich habe überhaupt nichts umgeschwenkt, ich hatte lediglech Hyperion gefragt, warum wir überhaupt streiten, webnn er meint,l dass auch mit compile und exec ausgeführter Code 'importiert' wäre:
Und statt über etwas zu streiten, sollten wir uns bemühen, da einen Unterschied zu erkennen oder festzulegen, denn wer einen Unterschied erkennt, kann das ausnützen, um etwas zu implementieren. Wer keinen Unterschied erkennt oder erkennen will, kann einen solchen leider nicht für eine Implementierung benützen.
Wenn im Mainscript genau das steht und sonst nichts:Dann ist das kein Code für ein Script oder ein unfertiger Code für ein Script. Hier wird eine Funktion definiert, aber nicht aufgerufen. So etwas macht man bei Modulen. Man importiert sie um dort Funktionen aufzurufen.
In einem Script dagegen befinden sich viele Funktionsaufrufe und auch viele Zeilen beginnen auch ganz links ohne in Funktionen eingebunden zu sein. Das mag für ein Modul für die Initialisierungsphase ja auch durchaus zutreffen. Aber in einem Script verwendet das Script alle in ihm definierten Funktionen selber und keine Funktion darin ist dafür gedacht, von außerhalb aufgerufen zu werden und idealerweise soll ein Zugriff von außerhalb auch gar nicht möglich sein.
Reicht das so mal für das Erste als grober Unterschied?
Code: Alles auswählen
Und in Deinem Post schreibst Du jetzt sogar, dass was ich tue, nämlich compile und exec auch importiert wäre. Ja wozu streiten wir uns dann überhaupt? Dann kann ja jeder zufrieden sein, denn ich habe es ja dann doch importiert, oder?
Wenn im Mainscript genau das steht und sonst nichts:
Code: Alles auswählen
def no_script():
print("I'm a script")
In einem Script dagegen befinden sich viele Funktionsaufrufe und auch viele Zeilen beginnen auch ganz links ohne in Funktionen eingebunden zu sein. Das mag für ein Modul für die Initialisierungsphase ja auch durchaus zutreffen. Aber in einem Script verwendet das Script alle in ihm definierten Funktionen selber und keine Funktion darin ist dafür gedacht, von außerhalb aufgerufen zu werden und idealerweise soll ein Zugriff von außerhalb auch gar nicht möglich sein.
Reicht das so mal für das Erste als grober Unterschied?
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
Wozu streiten wir uns überhaupt? Nur weil das von meinem Programm erzeugte ASCII Datenformat eine rein zufällige starke Ähnlichkeit mit Python Code besitzt - ok nicht rein zufällig und auch nicht nur starke Ähnlichkeit - sondern 100% - ich hatte eben gedacht ich tue jemandem einem Gefalllen, wenn Python mit tkinter auch so aussieht wie Python mit tkinter - nur deshalb muss dieses ASCII Format unbedingt als Python Module mit 'import' implementiert werden?
Irgendwelche Daten in irgendwelcher Form sollten keinesfalls als Module importiert werden. Vielleicht sollte man da die Syntax ändern, damit man nicht auf solche dummen Ideen kommt - dumm wären die gar nicht - aber die Forderung dass es so sein müsse, die zeigt von Engstirnigkeit.
Wie wäre es etwa mit ';' nach jedem Statement. Und statt ':' und eingerückt geschweifte Klammern. Statt def sollte es function heißen. Class sollte man groß schreiben und statt 'import' besser 'include'.
Würde das reichen um von der Forderung nach 'import' Abstand zu nehmen? Oder wären weitere Modifikationen nötig - dass man in etwa in die Richtung php, javascript, C# oder auch squirrel geht?
Irgendwelche Daten in irgendwelcher Form sollten keinesfalls als Module importiert werden. Vielleicht sollte man da die Syntax ändern, damit man nicht auf solche dummen Ideen kommt - dumm wären die gar nicht - aber die Forderung dass es so sein müsse, die zeigt von Engstirnigkeit.
Wie wäre es etwa mit ';' nach jedem Statement. Und statt ':' und eingerückt geschweifte Klammern. Statt def sollte es function heißen. Class sollte man groß schreiben und statt 'import' besser 'include'.
Würde das reichen um von der Forderung nach 'import' Abstand zu nehmen? Oder wären weitere Modifikationen nötig - dass man in etwa in die Richtung php, javascript, C# oder auch squirrel geht?
@Alfons Mittelmeyer: wie oft denn noch. Es gibt keinen Unterschied zwischen einem Skript und einem Modul. Jede .py-Datei kann man importieren. Ob das sinnvoll ist oder nicht, entscheidet nur der Author. Wenn man Funktionalität braucht, die in einer anderen .py-Datei steht, dann wird diese importiert. Daher muss sie auch so geschrieben sein, dass sie sinnvoll importierbar ist. Du kannst natürlich auch nicht sinnvoll importierbare "Skripte" (Dein Wortlaut) schreiben, wo Du dann zusätzlich noch irgendwelche compile-Magie brauchst. Du kannst aber auch, wenn Du in den Nachbarort willst, einmal um die ganze Welt laufen.
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@Sirius3 Ja genau darum geht es. Du hattest geschrieben: Da bin ich ganz Deiner Meinung. Das schließt aber auch ein, dass man nicht importiert, was äußerst unsinnig ist, dass man es importiert.
Was ein Script ist und ein Modul mag jeder nennen oder will. Ich verstehe unter Modul ein mit import importiertes Modul. Dann schreibe ich eben in Zukunft statt Modul eben jedes Mal 'mit import oder dessen Derivaten (etwa imp.load' ) importiertes Modul'. Vielleicht wird es dann deutlicher. Vielleicht kann mir dann auch jemand schreiben, wie ich am Besten das Main Script nennen soll, das ja anscheinend auch ein Modul genannt wird aber ein nicht 'mit import oder dessen Derivaten (etwa imp.load' ) importiertes Modul' ist.
Ach nochmals zurück zum Mainscript. Das aufzurufen ist keine 'Magie'. Wenn es zu lang ist, kann man es auch in kleinere Teile teilen, die man dann vor Python3 mit 'filexec' ausführen konnte. Da diese Funktion aber unnötig ist, weil sie aus einem kurzen Ausdruck mit drei Komponenten gebildet werden kann, hat man in Python3 darauf verzichtet. Ebenso wenig wie die Ausführung des Main Scripts sollte man die Ausführung durch 'filexec' oder den in Python3 gebräuchlichen Ausdruck 'Magie' nennen. Also von 'compile' Magie zu sprechen, dafür gibt es keinen Grund, es sei dem, man würde Computer, Compiler, Programmiersprachen und dergleichen als großen Zauber ansehen.
Und 'filexec' kann man auch lokal innerhalb einer Funktion ausführen. Damit hat das, was ausgeführt wird, nur temporäre und lokale Gültigkeit innerhalb dieser Funktion und wandert nach Beendigung dieser Funktion in den Garbage Collector, zumindest, was davon nicht noch global irgendwie referenziert ist, etwa durch die nicht nur lokal bestehenden tkinter Widgets und eine Referenz in deren command oder deren 'bind' eines Events.
Und genauso gehört sich das auch. Dagegen ist das unbedingte global Importieren Wollen von lokalen Variablen durch 'import' eines Moduls, bevor die Funktion beendet wird und der Garbage Collector greift, eine der hirnverbranntesten Ideen, die mir untergekommen ist und mir unbegreiflich, wieso man das so will.
Sicher lassen sich gewissse Variableninhalte irgendwie vor Rücksprung aus einer Funktion auch in ein File schreiben, das man dann danach importieren kann. Man muss sich dann nur überlegen, wie man dabei mit referenzierten Objekten umgeht und wie man die dann adäquat herausschreiben kann. Bei den tkinter Widgets könnte ich durchaus helfen. Andere Objekte muss man sich selber überlegen.
Code: Alles auswählen
Wenn man Funktionalität braucht, die in einer anderen .py-Datei steht, dann wird diese importiert. Daher muss sie auch so geschrieben sein, dass sie sinnvoll importierbar ist.
Was ein Script ist und ein Modul mag jeder nennen oder will. Ich verstehe unter Modul ein mit import importiertes Modul. Dann schreibe ich eben in Zukunft statt Modul eben jedes Mal 'mit import oder dessen Derivaten (etwa imp.load' ) importiertes Modul'. Vielleicht wird es dann deutlicher. Vielleicht kann mir dann auch jemand schreiben, wie ich am Besten das Main Script nennen soll, das ja anscheinend auch ein Modul genannt wird aber ein nicht 'mit import oder dessen Derivaten (etwa imp.load' ) importiertes Modul' ist.
Ach nochmals zurück zum Mainscript. Das aufzurufen ist keine 'Magie'. Wenn es zu lang ist, kann man es auch in kleinere Teile teilen, die man dann vor Python3 mit 'filexec' ausführen konnte. Da diese Funktion aber unnötig ist, weil sie aus einem kurzen Ausdruck mit drei Komponenten gebildet werden kann, hat man in Python3 darauf verzichtet. Ebenso wenig wie die Ausführung des Main Scripts sollte man die Ausführung durch 'filexec' oder den in Python3 gebräuchlichen Ausdruck 'Magie' nennen. Also von 'compile' Magie zu sprechen, dafür gibt es keinen Grund, es sei dem, man würde Computer, Compiler, Programmiersprachen und dergleichen als großen Zauber ansehen.
Und 'filexec' kann man auch lokal innerhalb einer Funktion ausführen. Damit hat das, was ausgeführt wird, nur temporäre und lokale Gültigkeit innerhalb dieser Funktion und wandert nach Beendigung dieser Funktion in den Garbage Collector, zumindest, was davon nicht noch global irgendwie referenziert ist, etwa durch die nicht nur lokal bestehenden tkinter Widgets und eine Referenz in deren command oder deren 'bind' eines Events.
Und genauso gehört sich das auch. Dagegen ist das unbedingte global Importieren Wollen von lokalen Variablen durch 'import' eines Moduls, bevor die Funktion beendet wird und der Garbage Collector greift, eine der hirnverbranntesten Ideen, die mir untergekommen ist und mir unbegreiflich, wieso man das so will.
Sicher lassen sich gewissse Variableninhalte irgendwie vor Rücksprung aus einer Funktion auch in ein File schreiben, das man dann danach importieren kann. Man muss sich dann nur überlegen, wie man dabei mit referenzierten Objekten umgeht und wie man die dann adäquat herausschreiben kann. Bei den tkinter Widgets könnte ich durchaus helfen. Andere Objekte muss man sich selber überlegen.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Richtig! Solche Sachen importiert man nicht und gut ist. Denn wenn es unsinnig ist, ein Modul zu importieren, dann nutzt man es natürlich auch nicht über andere finstere schwarze Magie, wie Du sie betreibst. Man nutzt es einfach gar nicht, überhaupt nicht. Deutlicher kann ich es nicht ausdrücken...Alfons Mittelmeyer hat geschrieben:Das schließt aber auch ein, dass man nicht importiert, was äußerst unsinnig ist, dass man es importiert.
Module müssen genau wie Klassen, Funktionen und jedes andere Python Konstrukt sorgfältig gestaltet werden, denn nur dann kann uns will man diese auch benutzen.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@Hyperion Ruf einfach Python nicht auf. Denn danach wird - sofern angegeben - das Mainscript ausgeführt. Und wenn Du so etwas als 'finstere schwarze Magie' ansiehst, dann lass es einfach bleiben.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Stellst Du Dich absichtlich dumm? Natürlich gibt es immer und in jeder Sprache irgend einen Einstiegspunkt, der ggf. andersartig ist oder bestimmten besonderen Konventionen folgt. Das ist übrigens auch in C so, was Du doch so super beherrschst, wie ich mich dunkel erinnere...
Das ist aber von der Sprache so vorgesehen und stellt den idiomatischen Weg dar, das zu tun. In Python ist das eben der ``if __name__ == "__main__"`` Hook. Aber von diesem Punkt an, nutzt man dann ``import``, um Code aus anderen Modulen zu verwenden.
Das sind einfach Fakten und anerkannte Konventionen. Es würde Dir gut tun, Dich endlich einmal vernünftig damit zu befassen. Du könntest so viel bessere Software schreiben, wenn Du Dich nicht dermaßen unverständlicher Weise dem Erlernen von Python verweigern würdest... und Du würdest Dich hier nicht so sozial ins Abseits stellen!
Das ist aber von der Sprache so vorgesehen und stellt den idiomatischen Weg dar, das zu tun. In Python ist das eben der ``if __name__ == "__main__"`` Hook. Aber von diesem Punkt an, nutzt man dann ``import``, um Code aus anderen Modulen zu verwenden.
Das sind einfach Fakten und anerkannte Konventionen. Es würde Dir gut tun, Dich endlich einmal vernünftig damit zu befassen. Du könntest so viel bessere Software schreiben, wenn Du Dich nicht dermaßen unverständlicher Weise dem Erlernen von Python verweigern würdest... und Du würdest Dich hier nicht so sozial ins Abseits stellen!
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
@Hyperion ja, das Main Script als Einstiegspunkt, das ist wohl 'gute und weiße Magie' aber 'filexec' das ist dann bei Dir 'finstere schwarze Magie'. Ja sind wir hier im Mittelalter? Und Du bist so etwas wie der Großinquisitor?