Das deutsche Python-Forum

Hallo Liebe Python Community,
Ich habe mich bereits ein bisschen in Python eingearbeitet. Ich bin sehr begeistert darüber, wie man
mit wenigen Zeilen Code zum Teil komplexe Dinge erledigen kann. Zukünftig plane ich die ausschließliche Benutzung von Python 3.7 und neueren Versionen. Mit veralteten Versionen und deren inkompatiblen Syntax möchte ich mich nicht herumschlagen müssen.

Ich würde gerne mit Python3.x Programme schreiben, die eine grafische GUI besitzen und als natives Programm unter den drei Betriebssystemen Windows, macOS und Linux laufen. Native deshalb, weil ich möglichst performante Programme schreiben will, die mit der Verarbeitung und der Anzeige großen Bilddateien zurechtkommen. Aber fast noch wichtiger ist mir, dass die Anwender ohne spezielle Computerkenntnisse meine Programme installieren und ausführen können. Da wäre z.B. die Notwendigkeit zuerst Python Installieren zu müssen völlig inakzeptabel. Der Anwender soll nichts über die verwendete Programmiersprache wissen müssen, genau so, wie es bei Compiler-Sprachen völlig normal ist.

Das einzige was ich bisher gefunden habe ist BeeWare zusammen mit Toga. Deren Feature-Liste liest sich sehr gut und es scheint genau das zu sein, was ich suche. Doch leider scheitert jeder Versuch es zu verwenden mit – für mich – nicht behebbaren Fehlern. Selbst schon die „Hello World“ Beispiele bekomme ich nicht zum Laufen. Das Projekt bittet nur über Twitter Support. Vorsichtig ausgedrückt finde ich Twitter für diese Zwecke nicht wirklich hilfreich.

Wenn ich die Suche hier im Forum benutze, finde ich zu Toga 0 Treffer und zu BeeWare eine Menge unrelevante Einträge, die das Wort BeeWare noch nicht einmal enthalten. Hier scheint das Thema noch nicht vorgekommen zu sein.

Nun meine Fragen:
Hat es jemand von Euch geschafft BeeWare zum Laufen zu bekommen und könnte mir dabei helfen? Ich könnte dafür ein weiteren Fehlversuch dokumentieren. Ich würde gerne unter Windows programmieren aber eine beliebige Linux-Version als Gastsystem ginge auch, falls da die Erfolgsaussichten besser wären.

Alternativ dazu: Gibt es gute Alternativen mit bessern Support? Wer hat womit gute Erfahrungen mit dem Kompilieren von Python-Programmen gemacht? Ich könnte zur Not auch damit leben, für alle drei Betriebssysteme eine eigene Tool-Chain benutzen zu müssen. Deshalb bin ich auch an Hinweisen zu solchen Lösungen interessiert.

Vielen Dank im voraus,
Johannes

Ich glaube da liegt ein großes Missverständnis vor: unter keiner Plattform gibt es native Python Programme in dem Sinne wie du das meinst. Python ist immer interpretiert. Die diversen Installer-Generatoren (py2exe, pyinstaller, py2app, ...) bündeln lediglich Geschickt einen Interpreter, Bibliotheken und deinen Code - in Form von PYC-Dateien, also nicht sofort lesbar. Aber auch nicht sehr schwer “knackbar”.

Das schließt deinen Anwendszweck nicht aus - zb erlauben numpy und OpenCV performantes arbeiten mit Bilddaten. Aber das ist trotzdem nicht, was du beschreibst.

Die Ziele bezüglich Nutzerfreundlichkeit und verschiedenen Plattformen (die man allerdings haben muss! Es gibt kein “crosscompiling”!) sind dann aber schon erreichbar.

Von BeeWare habe ich noch nie gehört. Der Autor von dem hier https://build-system.fman.io/ treibt sich hier gelegentlich rum.

JohannesS hat geschrieben: Dienstag 3. September 2019, 21:30 Wenn ich die Suche hier im Forum benutze, finde ich zu Toga 0 Treffer und zu BeeWare eine Menge unrelevante Einträge, die das Wort BeeWare noch nicht einmal enthalten. Hier scheint das Thema noch nicht vorgekommen zu sein.

Ich zitiere mal ein 6 Monate altes Statement des Gründers von Beeware (https://www.reddit.com/r/Python/comment ... he_moment/): "However, if you're adventurous, you've don't need something that works right now, and you're willing to roll up your sleeves and debug problems as they spring up, then maybe BeeWare is worth considering."

Das Interesse daran sich in dieses Projekt im Alpha-Stadium einzubringen scheint nicht so groß zu sein. Es gibt wohl weniger Leute die so eine Lösung brauchen als man vielleicht annimmt.

@JohannesS: Welche Bibliothek möchtest du denn für die GUI benutzen?

__deets__ hat geschrieben: Dienstag 3. September 2019, 21:43 Ich glaube da liegt ein großes Missverständnis vor: unter keiner Plattform gibt es native Python Programme in dem Sinne wie du das meinst. Python ist immer interpretiert. Die diversen Installer-Generatoren (py2exe, pyinstaller, py2app, ...) bündeln lediglich Geschickt einen Interpreter, Bibliotheken und deinen Code - in Form von PYC-Dateien, also nicht sofort lesbar. Aber auch nicht sehr schwer “knackbar”.

Ich denke die Installer-Generatoren erzeugen ein Byte-Code aus den Python-Quelltexten, d.h. der Quelltext muss beim Ausführen nicht erneut übersetzt werden, statt dessen kann sofort der Byte-Code (die PYC-Dateien) interpretiert werden. Mag sein, das dies vielleicht nicht viel Geschwindigkeitsvorteil bringt, aber dies ist sowieso nur ein netter Nebeneffekt den ich gerne mitnehme. Die eigentlich wichtige Aufgabe ist doch das Packen der Anwendung in eine auslieferbare Form, so das es von Anwendern ohne spezielle Computer Kenntnisse eigenständig ausgerollt werden kann.
Das leicht „knackbar“ ist für mich irrelevant. Vorerst benutze ich Python nur privat. Da gebe ich gerne der Community etwas von dem zurück, was nie entstanden wäre, wenn ich mich nicht von dort bedienen könnte. Eine Einsatz im kommerziellen Umfeld ist solange völlig abwegig, solange ich keine Möglichkeit für ein vernünftiges Rollout gefunden habe. Würde ich damit beginnen eine handvoll Skripte ausliefern, würde ich meinen Arbeitgeber mehr schaden als ein Raubkopierer es je könnte. Nichts ist geschäftsschädigender als etwas als Lösung zu verkaufen, was dann beim Anwender als totale Fehlinvestition eingeschätzt würde, weil schon die Installation nicht beherrschbar ist.

__deets__ hat geschrieben: Dienstag 3. September 2019, 21:43 Das schließt deinen Anwendszweck nicht aus - zb erlauben numpy und OpenCV performantes arbeiten mit Bilddaten. Aber das ist trotzdem nicht, was du beschreibst.

Ich habe bereits eigene DLLs in C++ geschrieben, in denen ich OpenCV benutze. Diese in Python einzubinden wäre eines meiner nächsten Ziele.

__deets__ hat geschrieben: Dienstag 3. September 2019, 21:43 Die Ziele bezüglich Nutzerfreundlichkeit und verschiedenen Plattformen (die man allerdings haben muss! Es gibt kein “crosscompiling”!) sind dann aber schon erreichbar.

Mir stehen alle Betriebsysteme zur Verfügung (für macOS in VirtualBox hat mein PC aber leider zu wenig Arbeitsspeicher) und wenn man keine plattformabhängigen Teile einbaut (wie z.B. DLLs), dann sollte das auch Plattformübergreifend möglich sein, gerade weil es ja kein “crosscompiling” sondern eigentlich ein “cross packing” ist.

__deets__ hat geschrieben: Dienstag 3. September 2019, 21:43 Von BeeWare habe ich noch nie gehört. Der Autor von dem hier https://build-system.fman.io/ treibt sich hier gelegentlich rum.

Das sieht sehr interessant aus! Anscheint nur für Windows aber das alleine würde mich schon weiter bringen. Werde ich schnellstmöglich ausprobieren und dann berichten.

/me hat geschrieben: Dienstag 3. September 2019, 21:49 Ich zitiere mal ein 6 Monate altes Statement des Gründers von Beeware (https://www.reddit.com/r/Python/comment ... he_moment/):
..

Danke für diesen informativen Link! Leider ist es so wie ich befürchtet habe . Das Projekt steht noch ganz am Anfang.

/me hat geschrieben: Dienstag 3. September 2019, 21:49 .. Das Interesse daran sich in dieses Projekt im Alpha-Stadium einzubringen scheint nicht so groß zu sein. Es gibt wohl weniger Leute die so eine Lösung brauchen als man vielleicht annimmt.

Wenn es eine Lösung wäre, würden es sehr viele benutzen. Das sich bisher kaum einer dran beteiligt ist für mich nicht verwunderlich, denn wenn man es versucht, scheitert man schon an der fehlenden Anlaufstelle und der fehlenden Dokumentation des schon Vorhandenen. Man müsste schon engen persönlichen Kontakt zum Autor pflegen um überhaupt eine Chance zu haben. Jedenfalls ist Twitter bzw. Gitter kein brauchbares Medium zum Mitmachen an einen Softwareprojekt.

sparrow hat geschrieben: Mittwoch 4. September 2019, 05:26 @JohannesS: Welche Bibliothek möchtest du denn für die GUI benutzen?

Bei der Entscheidung stehe ich ganz am Anfang, weil ich noch keinerlei Erfahrungen mit einer plattformunabhängigen GUI gemacht habe. Beruflich programmiere ich ausschließlich für Windows, hauptsächlich mit Delphi das alle mitbringt bzw. es Drittanbieter gibt. Ich habe mich deshalb bisher nicht mit dieser Fragestellung beschäftigen müssen. War immer wohlbehütet was das betrifft und nun fürchte ich, dass ich zu verhätschelt bin

Am wichtigsten ist mir, dass ich mit Python nicht nur Skript schreiben kann sondern komplette Programme. Diese sollten auf jedem Fall alle Abhängigkeiten mitbringen, so das sie wenigstens problemlos auf allen Geräten laufen, auf dem das jeweilige Betriebssystem läuft. In Moment bin ich so pessimistisch, dass ich befürchte das Ziel der Plattformunabhängigkeit ist zu hoch gesetzt. Ich werde auf jedem Fall jeden Tipp von Euch nachgehen. Der von __deets__ ist der Erste. Das wäre dann Qt.

Ich frage mich, ob und wie mit Browser Anwendung eine performante Anwendung programmiert werden könnte. Immerhin schaffen es moderne Browser sehr gut mit Bildern umzugehen. Allerdings fühle ich mich nicht als Web-Designer und Anwendungen mit Internet/Server zwang sind nicht sonderlich attraktiv für mich. Anderseits scheint damit die Plattformunabhängigkeit am besten machbar zu sein. Ich hoffe hier gibt es noch mehr Python Programmierer mit positiven Erfahrungen mit einer möglichst ausgereiften Tool-Chain, die ein guten Packer integriert hat.

Wenn du schon gut mit Delphi kannst, kannst du natürlich auch dabei bleiben. Oder bei dem Open-Source-Pendant Lazarus. Damit lässt sich das Projekt auch auf verschiedenen Betriebssystemen kompilieren.

Zu Qt: Großartiges Toolkit für die GUI und noch sehr viel mehr. Bedenke, dass Qt zwar unter der LGPL steht, die meist verwendete Schnittstelle pyQt jedoch unter der GPL. PySide2 als pyQt-Ersatz steht unter der LGPL.

Pyinstaller sollte das tun, was du möchtest. Ich würde aber dem Nutzer die beide Möglichkeiten eröffnen. Entweder den ganzen Scheeball mit Interpreter oder nur das reine Programm.

Das von mir zitierte fman build system unterstuetzt Windows und Mac. Ob ein Vorgehen mit Installer unter Linux ueberhaupt notwendig/wuenschenswert ist, steht auf einem anderen Blatt - da kann man ueblicherweise die gewuenschten Dependencies einfach per apt-get installieren (wenn die Versionen tolerant genug sind).

Was den Browser als Plattform angeht: du verraetst nicht was du en Detail erreichen willst, aber inzwischen gibt es Game-Engines, Musikproduktion, Office-Suiten etc im Browser. Da muss es schon sehr speziell zugehen, dass es *nicht* geht. Es bricht ggf mit geliebten Paradigmen. Ein Missverstaendnis ist aber, dass es dazu zwingend eines Servers im Sinne eines zentralen, im Web lebenden Servers geben muss. Der kann problemlos lokal als Teil der Anwendung laufen. Die hat dann zwar mehrere Prozesse unter der Haube, aber das ist ja nichts ungewoehnliches. Und aus Nutzersicht ist das nicht sichtbar. Eine Liste von Anwendungen, die mit Electron gebaut wurden, findet sich zB hier: https://electronjs.org/apps

JohannesS hat geschrieben: Mittwoch 4. September 2019, 09:38 Ich denke die Installer-Generatoren erzeugen ein Byte-Code aus den Python-Quelltexten, d.h. der Quelltext muss beim Ausführen nicht erneut übersetzt werden, statt dessen kann sofort der Byte-Code (die PYC-Dateien) interpretiert werden.

Das hast du auch ohne Installer. Wenn das Programm einmal gelaufen ist sind die PYC-Dateien da und werden beim nächsten Mal verwendet.

Ich habe mich nun mit FBS beschäftigt und bin positiv überrascht. Zwar habe ich es bisher nur unter Windows 7 mit ein extra dafür angelegten Python 3.6 Environment probiert. Dies aber ohne auf irgend ein nennenswertes Problem gestoßen zu sein. Nun verstehe ich auch, warum das “cross packing” nicht geht. Es werden native Programme zum Erzeugen der Setups benutzt. Da es aber eine „freeze“ Zwischenstufe gibt, in der alles in ein Verzeichnis „zum Mitnehmen“ gepackt wird, ist das überhaupt kein Problem. Ich bin begeistert! Schonmal ein herzliches Dankeschön an Michael Herrmann den Autor von FBS. Fman kannte ich noch nicht, sieht sehr interessant aus.

@__deets__:
Es werden alle drei Betriebssysteme unterstützt. Unter Linux wird fpm benutzt. Aus Sicherheitsgründen wäre es natürlich besser den Packetmanager zu benutzen, um zeitnahe herauskommende Sicherheitsupdates eingespielt zu bekommen. Aber bereits bei den wenigen Erfahrungen die ich mit Python gesammelt habe, halte ich die Wahrscheinlichkeit das ein einigermaßen komplexes Anwenderprogramm nach ein solchen Update noch funktioniert für sehr gering. Da teste ich lieber zuerst bei mir und wenn es funktioniert stoße ich das Rollout selbst an.

Mit ein lokalen Server könnte ich mich anfreunden. Die Werbung für Electron habe ich mir bereits angeschaut. Sieht sehr interessant aus, aber konnte auf die Schnelle keinen Bezug zu Python finden. Scheint mehr auf Note.js und JavaScript zu basieren. Wie geschieht da die Anbindung an Python?

>Was den Browser als Plattform angeht: du verraetst nicht was du en Detail erreichen willst
Das will ich gerne verraten, schon weil ich auch dafür mir Hilfe von hier erhoffe. Aber ich mache lieber ein eigenen Thema dafür auf. Hier würde es zu sehr von diesem Thema wegführen, weil es hier nicht um Entscheidungen geht, die ich an einen konkreten Vorhaben festmachen will. Nur so viel: es geht um eine Live-Bild Darstellung wie es im Browser üblich ist. D.h. das Bild läuft schon ein, während es noch nicht fertig bearbeitet, bzw. heruntergeladen ist.

Electron ist standardmaessig Node.js im Backend, aber nichts hindert dich daran, da stattdessen Python zu verwenden: https://www.techiediaries.com/flask-electron-tutorial/

Aber fuer die GUI ist in dem Moment natuerlich HTML/CSS/JS angesagt. Auf der anderen Seite sind das die modernsten und schicksten GUIs die man so kriegen kann.

Allerdings ist Qt auch sehr gut zu gebrauchen, insofern - wenn fbs tut, was du willst, und du dich mit den verwandten Lizenzen (Achtung PyQt ist GPL!) anfreunden kannst, ist eine gute Wahl. Bezueglich der Lizenz: nichts hindert dich daran, ein auch kommerziell vertriebenes Programm so zu lizensieren, und musst dann nur bereit sein auf Anforderung die Quellen offen zu legen. Das ist IMHO weniger schlimm als viele denken, denn letztlich ist es das persoenliche Commitment eines Entwicklers, das ein Projekt erfolgreich macht. Zumindest wenn man es an eine ueberschaubare, direkt beratene Klientel verkauft. Oder wenn man den Schritt geht, schluckt man eben die Lizenzkosten (paar hundert Euro). Die sollten ja beim Verkauf einer Software nun nicht das Problem darstellen.

@JohannesS: Nach Sicherheitsupdates sollte ein Programm weiterhin funktionieren. Solche Updates ändern ja nichts an der API der Bibliotheken sondern fixen Sicherheitsprobleme innerhalb des Codes. Sollte sich doch eine API-Änderung ergeben, dann ja in der Regel weil die Schwachstelle nicht ohne eine Änderung dort behoben werden konnte – dann will man ja aber auch nicht, dass das Programm einfach weiter läuft. Und wenn man ein Paket für eine bestimmte Distribution oder auch etwas schwammiger „alles was auf Debian xy basiert“ schnürt, dann sind die Versionsnummern der Bibliotheken in der Regel ja fest.

Was sich auf jeden Fall anbietet wäre es das Programm ganz normal mit ``pip`` installierbar zu machen, und eventuell sogar in den Python Package Index zu stellen, und eine kleine Anleitung wie man das mit ``venv`` und ``pip`` oder ``pipenv`` in eine virtuelle Umgebung installieren kann. Das erfordert dann zwar ein ganz kleines bisschen mehr als den total ”ahnungslosen” Endanwender, funktioniert dafür aber „cross plattform” ganz gut.

Electron hat keinen speziellen Bezug zu Python, man kann es aber natürlich auch verwenden für's Backend. fpm versucht in gewisser Weise ein Ersatz dafür zu sein, allerdings mit Qt statt Browser für die GUI. Es ging mehr um die Idee. Fast alle Webrahmenwerke in Python bringen einen eigenen kleinen Entwicklungsserver mit. Wenn man dann seine Webanwendung mit einem kleinen plattformspezifischen Starterskript versieht, kann man diesen Webserver lokal starten und die URL auch gleich in einem Browser aufrufen.

Bei Python fällt mir als Beispielanwendung sofort Jupyter Notebooks beziehungsweise Jupyterlab ein.

/me hat geschrieben: Mittwoch 4. September 2019, 13:42

JohannesS hat geschrieben: Mittwoch 4. September 2019, 09:38 Ich denke die Installer-Generatoren erzeugen ein Byte-Code aus den Python-Quelltexten, d.h. der Quelltext muss beim Ausführen nicht erneut übersetzt werden, statt dessen kann sofort der Byte-Code (die PYC-Dateien) interpretiert werden.

Das hast du auch ohne Installer. Wenn das Programm einmal gelaufen ist sind die PYC-Dateien da und werden beim nächsten Mal verwendet.

Achso, dann gibt es als kein Geschwindigkeitsvorteil. Das ist schade. Aber der Installer sorgt dafür, dass die mitgelieferte Python-Version benutzt wird, nicht die unter Umständen auf dem Zielsystem global im Path liegende Version - was nicht lange gut gehen würde.

Huch, warum würde das denn nicht lange gut gehen?

@sparrow: Wenn das auf aktuellen aber stabilen Debian-Systemen laufen soll, dann ist da eventuell nur Python 3.5 global installiert. JohannesS möchte aber in Python 3.7+ programmieren.

JohannesS hat geschrieben: Mittwoch 4. September 2019, 09:38 Beruflich programmiere ich ausschließlich für Windows, hauptsächlich mit Delphi das alle mitbringt bzw. es Drittanbieter gibt. Ich habe mich deshalb bisher nicht mit dieser Fragestellung beschäftigen müssen. War immer wohlbehütet was das betrifft und nun fürchte ich, dass ich zu verhätschelt bin

Ich würde das nicht ganz so hart formulieren, aber einen Eindruck in der Richtung hatte ich ehrlich gesagt auch. Ich hoffe, du nimmst das nicht persönlich, aber hier im Forum tauchen Fragen, die deiner ähneln, relativ oft auf. Gerade Personen, die aus der Windows-Ecke kommen, scheinen oft die Vorstellung zu haben, dass ein Programm etwas ist, was als autonome Exe-Datei daher kommt die man installieren oder gleich ausführen kann und die etwas zum Klicken anbietet. Python wurde aber zunächst einmal für das eher experimentelle Amoeba System entwickelt und ist nach meinem Eindruck insb. auf Unix-Systemen "groß" geworden. Auf Unix Systemen installiert man Pakete (heute) meist über Paketmanager, die sich um das Abhängigkeitsmanagement kümmern und die Verteilungen von Programmen erfolgt nicht selten im Quelltext. Python-Programme sind für mich persönlich daher in erster Linie etwas, das keine GUI hat/braucht und über einen Paketmanager installiert werden kann (ein frühes Gegenbeispiel von 1995 für ein in Python entwickeltes GUI Programm ist der Webbrowser Grail von Guido von Rossum, dem Erfinder von Python). Aus meiner Sicht sollte man finde ich zumindest im Hinterkopf bekommen, dass Python historisch eher einer etwas anderen Philosophie folgt. Ich würde nicht behaupten, dass man mit Python keine Cross-Plattform GUI-Anwendungen im Windows-Stil schreiben kann (die anderen hier im Thread haben dir ja schon wertvolle Hinweise gegeben und habe den Eindruck, es passiert in dem Bereich ein bisschen etwas, weil mit der wachsenden Python-Anwenderbasis scheinbar auch immer mehr Leute dazu kommen, diesen Anspruch an die Sprache habe). Persönlich würde ich das nur eher nicht machen, sondern bei deinen Anforderungen halt zu etwas aus der Kategorie C++, Java, C#, oder von mir aus auch Delphi/Kyle/Lazarus greifen.

Jetzt sind es so viele Antworten geworden, dass ich nicht mehr auf jedem Einzelnen eingehen kann. Danke dafür!

Das ich mich nicht mehr gemeldet habe liegt daran, dass ich zu den gegebenen Tipps zuerst recherchieren muss. Damit bin ich aus Zeitgründen noch nicht weit gekommen. Die Schwierigkeit besteht ja darin, dass ich mich für eine Lösung entscheiden muss, noch bevor ich einschätzen kann, ob ich damit zurecht kommen werde. Möglichkeiten gibt es viele, aber meine Ressourcen reichen nur für immer nur ein Richtung. Ich muss aufpassen, dass ich mich nicht verzettle. Deshalb habe ich beschlossen mich nicht zu weit aus dem von mir beherrschten Bereich weg zu bewegen. Für den Anfang werde ich mich auf die Windows Programmierung beschränken und erst dann Linux und macOS dazunehmen, wenn ich mir sicher bin, dass die gewählte Lösung von mir beherrscht wird. Meine Entscheidung ist auf PyQt5 mit FBS gefallen. Hier bekomme ich den von mir als sehr wichtig erachteten Installer mit. Und Qt scheint eine große Anwenderbasis zu haben.

Im 1. Schritt werde ich versuchen mich in das Multithreading unter PyQt5 einzuarbeiten und dann muss ich herausfinden welche Bildkomponenten es für Qt5 gibt. Tipps diesbezüglich würde ich dankbar annehmen. Zur gegebenen Zeit werde ich sicher dafür eigene Themen aufmachen.

Auch wenn ich jetzt auf vieles was hier thematisiert wurde nicht weiter eingehe, bedeutet das nicht, dass es mich nicht interessiert. Ich habe alles mit Interesse gelesen und werde ggf. auf einiges zurückkommen. Zum Beispiel wie man eigene Pakete für pip einpflegen kann. Das wird dann aktuell, wenn ich beginne Linux mit einzubeziehen.

Vielleicht noch kurz aus meiner Erfahrung:

Beschäftige dich dann mit Problemen, wenn sie auftreten. Nicht vorher.

Irgendwo oben hast du davon gesprochen, dass nativer Code schneller wäre. Ich hatte mit Python noch nie ein Geschwindigkeitsproblem. Solltest du eins kriegen, löse es dann, wenn es da ist. Nicht jetzt.

Das selbe gilt für die Art der Auslieferung. Schreib erst einmal ein Programm. Und wenn das fertig ist, mach dir Gedanken, wie man es verteilen kann. Vorher könnte es verlorene Zeit sein.

Multi threading und Python ist schwierig. Wenn du wirklich number crunching machen willst, brauchst du das Modul multiprocessing. Oder nutzt viel Bibliotheken wie opencv und Numpy, die das sogenannte GIL freigeben wenn sie rechnen.