[Überarbeitet] Umstieg von Basic auf Python: Erfahrungsbericht

[preklov]

Es hatte mich gereizt, bei in einem Dokument eingebettetem Code von Basic nach Python zu wechseln. Es hat funktioniert, obwohl ich kein Experte in Python bin. Aber mir gefällt die Sprache.

Ich habe meine Erfahrungen in einer PDF-Datei zusammengefasst und zum Download auf meine Homepage gestellt:
https://www.uni-due.de/~abi070/count.ph ... ericht.pdf

Sagt es mir bitte offen, wenn das alles kalter Kaffee sein sollte oder wenn ich an der einen oder anderen Stelle falsch liege oder zu umständlich bin.

Schöne Grüße
Volker
https://www.uni-due.de/~abi070/

[edit] Die überarbeitete Fassung berücksichtigt Anmerkungen von Karolus.[/edit]

[Stephan]

Sagt es mir bitte offen, wenn das alles kalter Kaffee sein sollte oder wenn ich an der einen oder anderen Stelle falsch liege oder zu umständlich bin.

Ich habe, jetzt auf die Schnelle, das Dokument natürlich nur überflogen, aberr ich begrüße jede Aktivität die Wissen zur Python-Programmierung für/in OO/LO verbreitet und Nutzern hilft ihren Weg zu Python zu finden.

Ich erinnere mich noch sehr gut wie einst die Situation bei StarBasic war, es gab nur äußerst wenig Literatur und äußerst wenig Hilfe für Normalanwender, sondern nur im Internet verstreutes und verstecktes Wissen von Insidern. (Es gab hingegen recht viel Wissen zur Basic-Programmierung für Normalanwender des alten StarOffice, nur war dieses Wissen mit Aufkommen von OOo 1.x und StarOffice 6 faktisch überholt.)
Und so ähnlich steht es heute um die Python-Programmierung in Bezug auf OO/LO und das gilt es zu ändern und es stünde de.openoffice.info gut an diesbezüglich Vorreiter zu sein.

Betreffs Python bin ich selbst Lernender, auf leider bisher sehr niedrigem Niveau, aber als Moderator will ich gerne alles tun was ich kann um zu helfen das sich Python-Kenntnisse besser verbreiten können.
Schon vor einiger Zeit hatte ich Einzelne Python-Kenner angesprochen mit der Bitte doch entsprechendes Wissen in der FAQ abzulegen, aber vielleicht war das nicht der richtige Einstieg und man muss nach anderen Wegen Ausschau halten.

@Volker
Was ich spontan gerne täte wäre Deinen einleitenden Post hier nach "Wissensarchiv" (viewforum.php?f=25) zu duplizieren, damit er präsent bleibt. Ist das in Deinem Sinne?



Gruß
Stephan

[preklov]

@Stephan:

Was ich spontan gerne täte wäre Deinen einleitenden Post hier nach "Wissensarchiv" (viewforum.php?f=25) zu duplizieren, damit er präsent bleibt. Ist das in Deinem Sinne?

Es ist in meinem Sinne. Ich hoffe allerdings, dass der Inhalt nicht in die Irre führt. Immerhin ist es ein Dokument über einen Lernprozess.

Schöne Grüße
Volker

[Karolus]

Hallo

Ich bin gerade beim "überfliegen" der pdf, und kann soweit bestätigen das es gut strukturiert erklärt ist und keine groben Fehler enthält.

Im folgenden Kommentiere ich (IHMO) kleinere Fehler:

@ 3.) Bibliotheken und Module

Die OO-Basic-Strukturen kennen die Aufteilung in
Bibliotheken und Module. Python kennt nur Bibliotheken (Libraries). Der in einer Datei zusam-
mengefasste Code ist eine Library. Eine Untergliederung in Module ist nicht vorgesehen.

das ist so nicht richtig, python benutzt sehr wohl den Begriff `module` sogar semantisch analog zu Basic:

Code: Alles auswählen

>>> import zipfile
>>> zipfile
<module 'zipfile' from '/usr/lib/python3.4/zipfile.py'>

@ 3.) ...ein paar Zeilen weiter unten:
Deine Motive für den Importhook kann ich nicht so ganz nachvollziehen, warum speicherst du die "importierbaren" Sachen nicht einfach dort wo sie automatisch importierbar sind, nämlich in .../pythonpath/...



@ 4.5 ...ergänzend zur Behandlung von Datum/zeit Basic versus python
Der Basic-interpreter benutzt im Prinzip das gleiche Modell zur Darstellung und Berechnung von Datum und Zeit wie Calc:
Es wird grundsätzlich in "Fliesskomma-tagen" seit dem soffice-Basis-Datum gerechnet ( dem 30 Dezember 1899 0:00 uhr )

Python weiss von zunächst mal nichts von diesem Modell, es benutzt seine eigenen Bibliotheken die im Hintergrund im wesentlichen (wie alle Betriebssysteme auch) die "Fliesskomma-sekunden seit ... moment..., ich frage mal nach:

Code: Alles auswählen

>>> from datetime import _EPOCH
>>> _EPOCH
datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

....auf deutsch dem Basisdatum 1970-01-01 0:00 UTC benutzt

um einem Datums/zeitwert aus Calc heraus in ein Python-Datum zu übersetzen, müssten wir in etwa forlgendes tun:

Code: Alles auswählen

from datetime import datetime, timedelta
# Tag Null im Calc-universum
office_zero = datetime(1899,12,30)
print(office_zero)
doc = XSCRIPTCONTEXT.getDocument()

calc_now = doc.CurrentSelection.Value
#die Ausgabe von =JETZT() aus Calc ohne Formatierung
print(calc_now)
momentan = office_zero + timedelta(days=calc_now)
print(momentan)

mit der Ausgabe

Code: Alles auswählen

1899-12-30 00:00:00
42414.75233621262
2016-02-14 18:03:21.848771

[edit:18:06]die Zeitausgabe aktualisiert auf 18:03..[/edit]





@ 5.1 (auch 5.2, 5.3 ) Ereignisse, Buttons etc.
soffice reicht grundsätzlich an alle Prozeduren, die per Button oder Ereigniss in irgendeiner Form getriggert werden, eben diesen Aufrufkontext als Argument[e] durch, der python-Interpreter unterdrückt nur nicht stillschweigend die Tatsache einer Argumentübergabe wenn in der Methodensignatur gar keine definiert wurde.
(das ist IHMO in basic zumindest unsauber implementiert )
Allgemein sollte man als Programmierer (egal ob Basic, python,...) diese durchgereichten Argumente auch in der aufgerufenen Funktion benutzen und nicht ignorieren.

Code: Alles auswählen

def some_method( *args ): 

der asterisk bedeuted: die (Funktion|Methode) darf mit einer undefinierten Anzahl- ( einschliesslich null ) -von Argumenten aufgerufen werden.

[preklov]

Vielen Dank Karolus, für deine Anmerkungen.

@ 3.) Bibliotheken und Module

pdf.$3 hat geschrieben:
Die OO-Basic-Strukturen kennen die Aufteilung in
Bibliotheken und Module. Python kennt nur Bibliotheken (Libraries). Der in einer Datei zusam-
mengefasste Code ist eine Library. Eine Untergliederung in Module ist nicht vorgesehen.


das ist so nicht richtig, python benutzt sehr wohl den Begriff `module` sogar semantisch analog zu Basic:

Code: Alles auswählen
>>> import zipfile
>>> zipfile
<module 'zipfile' from '/usr/lib/python3.4/zipfile.py'>

Interessant. Aber mir scheint , als wenn das in der Praxis für den Nutzer nahezu identisch ist, abgesehen von von der Standard Library. Kann man das so sagen? Immerhin ist "module" keine Untergliederung von "library".

@ 3.) ...ein paar Zeilen weiter unten:
Deine Motive für den Importhook kann ich nicht so ganz nachvollziehen, warum speicherst du die "importierbaren" Sachen nicht einfach dort wo sie automatisch importierbar sind, nämlich in .../pythonpath/...

Das würde bedeuten, dass die Datei nicht einfach so weitergegeben werden kann. Dann wäre ein Add-On wohl besser. Oder sehe ich den Wald vor lauter Bäumen nicht?

Deine Tipps zur Datumsberechnung sind klasse. Ich werde den Abschnitt 4.5 überarbeiten.

Code: Alles auswählen
def some_method( *args ):

der asterisk bedeuted: die (Funktion|Methode) darf mit einer undefinierten Anzahl- ( einschliesslich null ) -von Argumenten aufgerufen werden.

Das ist sicherlich klarer ausgedrückt als meine Formulierung "Sequenz von Argumenten". Ich werde das ändern.

Schöne Grüße
Volker

[Karolus]

Hallo

Das würde bedeuten, dass die Datei nicht einfach so weitergegeben werden kann.

Warum ? wer hindert dich daran das Dokument selbst zu erweitern mit zusätzlich :

...Scripts/python/pythonpath/tools.py

Wenn die "Gesamtfunktionaltät" deines Projekts mit einer|m bestimmten Dokument gekoppelt ist, gib es doch als Dokument weiter, wenn das Projekt nichts Dokumentspezifisches tut wäre es wohl besser ein Addon.


nochmal zu `module` versus `Library` :

```module``` ist in beiden Fällen die Bezeichnung für eine Textdatei die eine oder mehrere (sub|def|class|function) definiert.

Library ist in Basic eine übergeordnetes Verzeichniss unterhalb des Basic-verzeichnisses.
diese zusätzliche Verzeichnissebene wird für Python nicht forciert, daher kann man direkt unterhalb von
../Scripts/python/ python-dateien respective "module" anlegen, nur für "import" benötigt man per soffice-konvention einen ../Scripts/python/pythonpath/blah.py

[preklov]

Warum ? wer hindert dich daran das Dokument selbst zu erweitern mit zusätzlich :

...Scripts/python/pythonpath/tools.py

Der Groschen ist endlich gefallen! Das gilt ja gar nicht ausschließlich auf der Benutzerebene.

Library ist in Basic eine übergeordnetes Verzeichniss unterhalb des Basic-verzeichnisses.
diese zusätzliche Verzeichnissebene wird für Python nicht forciert, daher kann man direkt unterhalb von
../Scripts/python/ python-dateien respective "module" anlegen, nur für "import" benötigt man per soffice-konvention einen ../Scripts/python/pythonpath/blah.py

Diese Differenzierung erscheint mir angebracht

Ich werde meinen Bericht korrigieren. Ich melde mich, wenn ich fertig bin. Das kann jedoch ein paar Tage dauern.

Schöne Grüße
Volker

[Karolus]

Hallo

Ich erinnere mich noch sehr gut wie einst die Situation bei StarBasic war, es gab nur äußerst wenig Literatur und äußerst wenig Hilfe für Normalanwender, sondern nur im Internet verstreutes und verstecktes Wissen von Insidern. (Es gab hingegen recht viel Wissen zur Basic-Programmierung für Normalanwender des alten StarOffice, nur war dieses Wissen mit Aufkommen von OOo 1.x und StarOffice 6 faktisch überholt.)
Und so ähnlich steht es heute um die Python-Programmierung in Bezug auf OO/LO und das gilt es zu ändern und es stünde de.openoffice.info gut an diesbezüglich Vorreiter zu sein.

@Stephan:
Dem letzten Satz kann ich so nicht zustimmen, es ist ja nicht so das jetzt alles was sich auf die soffice-API bezieht, in python ungültig ist oder sich nicht relativ einfach "übersetzen" lässt.
Die ( nebenbei bemerkt immense ) Grundlagen-Arbeit von Michael Dannenhöfer ist durchaus für "Python-schreiberlinge" wie mich auch heute noch hilfreich.
Die einschlägigen Entwicklerwerkzeuge Xray und im python-kontext doch eher MrI sind vorhanden.

Was in der Richtung fehlt ist ein einfaches plattformunabhänges Konzept[1] einer IDE die transparent auch noch ein wenig mehr kann als die relativ "dumme" Basic-IDE.
(@ Volker: Ich finde deine Idee, quasi auf der Struktur eines ausgepackten Dokuments zu arbeiten, und zum Testen mal fix per Script einpacken und ausführen ziemlich genial, insbesonder mit Bezug auf die integrierten Dialoge, mit dem Zeug hab ich mich noch nie wirklich befasst. )

[1]( Disclaimer: das folgende ist weder plattformunabhängig noch in jedem Fall einfach einzurichten) Ich selbst arbeite jetzt mehr oder weniger interaktiv in einer Jupyter notebook -sitzung (früher ipython notebook) in Zusammenarbeit mit LO im Pipe-modus ... die Details dazu würden das Thema hier überstrapazieren...

[mikeleb]

Hallo,

jetzt hab' ich mal einen nachvollziehbaren Einstieg und der macht Lust auf mehr.
@Volker: Tolle Arbeit
@karolus: Deine Erfahrungen sind unverzichtlich. Tolle Teamarbeit.
Ich mach dann mal den Tester (hoffentlich finde ich die Zeit dazu )
Die Sache mit der IDE wäre schon was mächtig gewaltiges ...

[Stephan]

Dem letzten Satz kann ich so nicht zustimmen, es ist ja nicht so das jetzt alles was sich auf die soffice-API bezieht, in python ungültig ist oder sich nicht relativ einfach "übersetzen" lässt.

Ja, stimmt da habe ich mich 'vergaloppiert' (ich meinte eigentlich nur die Sprache, aber ich schrieb ja nun einmal "in Bezug auf OO/LO"), also stimmt, Deine Kritik ist richtig.

Was in der Richtung fehlt ist ein einfaches plattformunabhänges Konzept[1] einer IDE die transparent auch noch ein wenig mehr kann als die relativ "dumme" Basic-IDE.

Das ist zutreffend, und ich würde noch etwas weiter gehen: die IDE sollte in OO/LO integriert sein (das müsste nicht 'nativ' sein, sondern könnte ja auch per Extension nachrüstbar sein), weil das Ganze sonst nicht wirklich normalanwendertauglich ist.
Die Probleme fangen schon da an wo der Anwender ein Script händisch in das Dokument packen muss, man kann den Vorgang so gut beschreiben wie man will, aus Anwendersicht erscheint dass alles nicht 'rund' wenn man es händisch machen muss.
Vergleichweise ist es heute auch bei Basic-Extensions noch so, denn dort ist eine große Zahl von Anwendern auf Tools wie BasicAddonBuilder angewiesen. Im Übrigen ist es auch für mich nervig und zeitfressend Vieles per Hand machen zu müssen.

imho:
Wenn sich Python in Praxis nicht durchsetzt dann auch, und ziemlich maßgeblich, wegen solch fehlenden Komforts bei der Programmierung, zumal viele Leute Umsteiger sind und VBA gewöhnt sind.
Das ist auch so zu beobachten wenn ich beruflich programmiere, nahezu kein Kunde will für die typischen kleinen Automatisierungen etwas Anderes als Basic, weil er dort häufig genügend Kenntnisse hat später selbst Änderungen vorzunehmen.
An Nachteile von Basic ist er hingegen von VBA gewöhnt und solange etwas in Basic geht (Einiges geht ja technisch wirklich nur in Python & co.) sind demgegenüber die Vorteile von Python nie so gravierend das es Anwender in großer Zahl überzeugt, z.B. der häufig erheblich kürzere Code, der natürlich auch leichter zu warten ist, bringt dann kaum merkliche Vorteile wenn es um typische kleine Automatisierungen geht, die häufig nur wenige hundert bis vielleicht einige tausend Codezeilen haben.
Leider wirkt in dieser Hinsicht auch jede Verbesserung bei der Ausführbarkeit von VBA in OO/LO in die quasi falsche Richtung denn es bestärkt eher am Festhalten an Basic.


Gruß
Stephan

[Stephan]

Ich werde meinen Bericht korrigieren. Ich melde mich, wenn ich fertig bin.

ich warte dann noch damit das in den anderen Forumsbereich zu stellen.


Gruß
Stephan

[preklov]

@Karolus
Ich teste gerade mit pythonpath. Ich habe den "Tools"-Code aus macros.py in die Datei toolbox.py übertragen.

Code: Alles auswählen

Scripts
   macros.py
   pythonpath
      toolbox.py

In META-INF/manifest.xml habe ich die zusätzlichen Eintragungen vorgenommen:

Code: Alles auswählen

<manifest:file-entry manifest:media-type="" manifest:full-path="Scripts/python/pythonpath/toolbox.py"/>
<manifest:file-entry manifest:media-type="application/binary" manifest:full-path="Scripts/python/pythonpath/"/>

Und in macros.py steht

Code: Alles auswählen

from toolbox import *

Beim Start einer Funktion kommt die Fehlermeldung:

[ERROR] <type 'exceptions.ImportError'>: type toolbox.* is unknown

Was läuft falsch?

Schöne Grüße
Volker

[Karolus]

Hallo

vermeide den *Sternchen-import und importiere explizit den|die Funktion|en die du benötigst.

[preklov]

vermeide den *Sternchen-import und importiere explizit den|die Funktion|en die du benötigst.

Code: Alles auswählen

from toolbox import msg_box

[ERROR] <type 'exceptions.ImportError'>: type toolbox.msg_box is unknown

Hast du das getestet?

Schöne Grüße
Volker

[Karolus]

Hallo

Nein, ich hab das noch nicht getestet, es gibt auch noch andere "Baustellen"

mglw. hast du eine andere toolsbox.py weiter oben im Suchbaum von python?

Karolus