Write funktioniert nicht.

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Sirius3
User
Beiträge: 17741
Registriert: Sonntag 21. Oktober 2012, 17:20

@LotharK: Bei Python gibt es keine komplizierten Build-Link-Deploy-Prozesse, weil ein Skript einfach gestartet wird und es läuft. Daher entfällt der offensichtlichste Grund einer Integrierten Entwicklungsumgebung. Wer mit einem riesigen Monster arbeiten will, dem wird oft PyCharm empfohlen.
Ein von microsoftlastigen Organisationen, die schonmal was von offenen Platformen gehört haben, oft begangener Weg ist es, auf dem Server ein in .NET geschriebener XMLRPC-Server, der einen Dienst zur Authentifizierung anbietet und mit der Datenbank redet. Aber auf jeden Fall lohnt es sich, .NET JsonRPC beizubringen, aber für beides gibt es auf Python-Seite passende Bibliotheken. Über Dateien zu gehen, ist umständlich, langsam, unflexibel und fehleranfällig.
Da in Python Fehler erst zur Laufzeit auffallen, die bei anderen Programmiersprachen schon beim Compilieren Fehler produzieren, ist es um so wichtiger, schon früh Tests für alle Funktionen zu schreiben. Da gibt's dann keine Ausreden dafür.
LotharK
User
Beiträge: 51
Registriert: Sonntag 22. März 2015, 10:02

Hallo Sirius3,

danke erst mal für Deine Ausführungen.

Na ja, in einer Programmierumgebung würde mir schon gefallen, wenn ich F5 drücke, wird das Programm gestartet. Python fragt jedes Mal, nach dem Speichern. Schon das allein nervt. Da ich nur so ein klitzekleines Projekt bewerkstelligen will, werde ich da nicht lange rum experimentieren, sondern mit der IDE arbeiten.

Im Grunde hast Du mit der Störanfälligkeit Recht. In meinem Falle ist's Bockwurst. Wenn Die Personalabteilung eine Änderung der Transponder / User-Daten vornimmt, wird einfach die komplette Datei neu ausgegeben. Personalnummer/Transpondernummer. Der Raspi schaut alle paar Minuten, ob es eine Datei neueren Datums gibt. Ist das der Fall, liest er die Datei ein. Die paar Leute sind in ein paar Sekunden in ein Dictionary eingelesen. Es handelt sich nur um 1260 DS. Ich hab es gerade getestet. Geht echt fix.
Sollte aus irgend einem Grund die Datei mal nicht zu lesen sein, na ja, da liest er sie eben in paar Minuten noch mal.
Klar ist das nur ne "Krücke" aber sollte erst mal funktionieren.
Ich will den Entwicklern von Python jetzt nicht zu nahe treten, aber als ich 87 mit Programmieren anfing, da war die Entwicklungsumgebung von Basic sogar besser als Python. Vielleicht mache ich ja auch nur was falsch. Sogar Assembler-Programme lassen sich mit AVR Studio besser testen. Und das ist wirklich hardwarenah.
Auf alle Fälle werde ich mir mal paar gute Bücher zulegen. Bis jetzt habe ich nur "Einstieg in RaspBerry Pi" von Daniel Kampert und dort tummeln sich ein paar echt böse Fehler.

Ciao LotharK
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

LotharK hat geschrieben: Ich will den Entwicklern von Python jetzt nicht zu nahe treten, aber als ich 87 mit Programmieren anfing, da war die Entwicklungsumgebung von Basic sogar besser als Python.
Du darfst nicht Sprache und Tooling drum herum vermischen! Insbesondere in Bezug auf IDEs. Ich habe anno '90 mit Basic auf dem C64 angefangen und würde nicht sagen, dass die Umgebung dort besser und komfortabler war, als eine stink normale Python-Shell!

Ich persönlich würde IDLE sofort aus dem Standard Python-Paket entfernen und maximal getrennt angeben. Eigentlich würde ich das das sogar komplett entfernen - oder man müsste es neu machen. Denn so wird es als eine Art IDE wahrgenommen, was IDLE aber nach heutigen Maßstäben nicht erfüllen kann.

Nimm doch einfach einen guten Editor und installiere Dir ipython. Mehr braucht es imho nicht.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
LotharK
User
Beiträge: 51
Registriert: Sonntag 22. März 2015, 10:02

Hi,
C64 - das waren noch Zeiten. Datasette, mein Gott.
iPython. Ich habe schon versucht, Informationen zu bekommen. Habe aber noch nicht das richtige Tutorial in deutsch gefunden.
Hast du da vielleicht einen Tipp?
Am liebsten wäre mir, wenn ich nicht auf dem Raspi programmieren müsste. Das kleine Fenster nervt ganz schön. Hab zuhause nur den Läppi.

Ciao LotharK
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Na, ipython ist ja nur eine etwas aufgemotzte Python Shell. Ich vermute mal, dass es da nicht unbedingt eine Dokumentation auf Deutsch gibt. Du musst Dich mit dem Gedanken anfreunden, dass Du vieles auf Englisch lesen musst, wenn Du Dich mit Python dauerhaft befassen willst.

Und in einer Shell programmiert man ja nichts größeres, sondern probiert nur kleine Dinge aus. Wenn Du dabei Raspi spezifische Dinge nutzt, wird das wohl auch nur auf einem System funktionieren, auf dem diese Libs zur Verfügung stehen...
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@LotharK:
Ich würde Dir empfehlen, dem Raspi ein X-System, einen Monitor und Tastatur zu spendieren und damit zu entwickeln (falls der Raspi das Antreiben kann, beim Modell A könnte das ein Problem sein) - sonst wird die Entwicklung zur fummeligen Terminalerfahrung. Du kannst natürlich auch vi/emacs im Terminal nutzen, allerdings bist Du dann wahrscheinlich die ersten 3 Monate damit beschäftigt, die grundlegende Bedienung zu erlernen.
Was auch noch geht - X Forwarding des Editorfensters vom Raspi auf Dein Windows (z.B. mit XMing). Allerdings dürfte der Raspi für eine IDE wie PyCharm zu schmalbrüstig sein. Falls Du das einsetzen willst, dann müsstest Du remote (auf Windows oder Linuxrechner) entwickeln, und könntest per Deployment-Setting die Änderungen auf den Raspi schieben. Für raspi-spezifische Sachen ist jedoch die remote-Entwicklung (vorallem mit Windows) mitunter etwas nervig, weil evtl. Bibliotheken oder Symbole, die Du brauchst, im Editor nicht zur Verfügung stehen. Da musst Du selber mal probieren, welche Vorgehensweise Dir besser liegt. IDLE hingegen - nunja, ist ein Löschkandidat ;)
Benutzeravatar
darktrym
User
Beiträge: 784
Registriert: Freitag 24. April 2009, 09:26

Gut zu wissen, nämlich DOS hat seinen Puffer noch entsorgt wie beschrieben.
„gcc finds bugs in Linux, NetBSD finds bugs in gcc.“[Michael Dexter, Systems 2008]
Bitbucket, Github
Antworten