Mal wieder was eher Philosophisches....

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.
ne0h
User
Beiträge: 115
Registriert: Samstag 16. Februar 2008, 11:35

Montag 5. Mai 2008, 19:03

Nabend werte Python-Gemeinde,

ich hab mal wieder ein philosophisch angehauchtes Thema, das mich beschäftigt.

Nun ja, heute kam es zu einer Diskussion zwischen mir und meinem Tutor, bezüglich Python und Shellscripting. Wir hatten als Aufgabe, eine Datei mittels eines Shell-Skriptes auszulesen, die Daten aufzubereiten, gewisse Berechnungen durchzuführen und das Ganze dann auch wieder auszugeben in der Shell.

Irgendwann wurde mir das Geskripte einfach zu nervig (klar, es ist im Grunde auch nur eine Gewöhnungssache, aber das ist bei jeder Sprache eben so) und ich habe den Tutor gefragt, ob Ihn persönlich die grauenhafte Syntax nicht stört.

Seine Antwort dazu war: "Er habe es ja nicht erfunden."

Ok, klar, das habe ich Ihm auch nicht vorgeworfen. Aber ich persönlich bin Jemand, der schnell die Lust verliert, wenn der eigentliche Kern, also das zu behandelnde Problem, sich in reinen syntaktischen Schwierigkeiten verzettelt bzw. verliert und man mit gewissen (in meinen Augen auch durchaus sehr merkwürdigen) Eigenheiten kämpfen muss, statt sich auf die Logik zu konzentrieren.

Insofern wurde meine Meinung bisher durch Python auch stets bestätigt, denn syntaktisch ist Python m.E. einfach ungeschlagen, die Eleganz und Klarheit macht mir das Programmieren einfach unglaublich angenehm und der Fokus liegt, zumindest bei mir, zu 95% auf der Programmlogik und nicht im Zwist der Klammern, Semikolons, "done"´s und "fi"´s (wie im Shellscripting), etc.....

Nun ist das auch nicht der Kern des Ganzen, ich will hier nichts schlecht reden und Jedem das Seine (Ich spreche der Shellprogrammierung auch Ihre schönen Seiten nicht ab, grep, cut, pipelining etc. sind mächtige Konstrukte :wink:). Aber da kam in mir im Laufe des Tages die Frage auf:

"Wofür würdest Du Python denn nicht(!) einsetzen?"

Hätte ich die Wahl, würde ich Python dem reinen Shellscripting in den meissten Fällen vorziehen. Ebenso, wenn es um kleine wie auch grosse Anwendungen geht, mit und ohne grafischer Oberfläche.

Abstriche sind natürlich vorhanden, wenn es in Richtung Betriebssystem und damit auch Speicherverwaltung, Pointer etc. geht. Da sind C/C++ wohl Standard und werden es auch vorerst bleiben.

Tja, Riesenprojekte gehen für mich in Richtung Java/C++ wobei ich mich hier frage, warum ich Python ein wirklich "grosses" Projekt (noch) nicht ganz zutraue ?! (Wobei auch hier die Dimension zu definieren ist. Was ist ein solches Projekt? SAP? MySQL? Apache? )

Also kurzum: Wie sieht es bei Euch aus? Welche Bereiche sind in Euren Augen von Python abgedeckt? Wo spielt Python seine Stärken aus? Wofür würdet Ihr Python niemals einsetzen?


Gruß


ne0h
sechsrad
User
Beiträge: 173
Registriert: Montag 31. März 2008, 17:09

Montag 5. Mai 2008, 19:43

Wie sieht es bei Euch aus? Welche Bereiche sind in Euren Augen von Python abgedeckt? Wo spielt Python seine Stärken aus? Wofür würdet Ihr Python niemals einsetzen?
schau hier ins forum, durch die vielen meinungen für verschiedene projekte habe ich das alles gelernt, was du gefragt hast. und wo ich meinte, das bestimmte dinge mir nicht passen, die habe ich weg gelassen und meine sachen reingesetzt.

tausend menschen > tausend meinungen > tausend lügen ?


Wofür würdet Ihr Python niemals einsetzen?
zum kinder zeugen.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 5. Mai 2008, 20:08

ne0h hat geschrieben:Tja, Riesenprojekte gehen für mich in Richtung Java/C++ wobei ich mich hier frage, warum ich Python ein wirklich "grosses" Projekt (noch) nicht ganz zutraue ?! (Wobei auch hier die Dimension zu definieren ist. Was ist ein solches Projekt? SAP? MySQL? Apache? )
Hallo ne0h!

Was sind Riesenprojekte? Das sind doch meist Projekte, die aus mehreren Programmen bestehen, richtig? Ist ein Projekt das aus mehreren Programmen besteht ein Riesenprojekt, oder sind das mehrere kleine Projekte? :-)

Wie auch immer. Ich kann mir vorstellen, dass man komplexe Echtzeitberechnungen nicht mit Python machen sollte. Aber da ich damit nichts zu tun habe, setze ich Python für alles ein was ich programmiere.

- Webanwendungen
- Point of Sale (Kassensysteme)
- Warenwirtschaft
- Bestellwesen
- Bankomatkartenschnittstelle
- Computerüberwachung (Fernüberwachung)
- Serverwartung (Sicherung, Logfileanalyse)
- Datenbankauswertung (Diagramme)
- DVD kopieren und Avidemux mit den richtigen Parametern starten
- Geburtstags- und Ereignisserinnerungen mir selber per Email schicken lassen
- Etiketten (Barcode) drucken
- Kaffeemaschinen ansteuern (RS-232)
- Kaffeemühlenkontrolle (RS-232)
- MP3/WMA --> OGG umwandeln (Mplayer, mp3info, oggenc2 und vorbiscomment mit Parametern aufrufen)
- Daten von und an Mikrocontroller empfangen und schicken (RS-232)
- Relais über Mikrocontroller ansteuern (RS-232)
- Servos (nur zum Test) steuern (RS-232 an Mikrocontroller)
- Schrittmotoren (nur zum Text) steuern (RS-232 an Mikrocontroller)
- Dateien vom Internet herunterladen (HTTP)
- Datenaustausch mit SAP-Systemen (FTP, CSV)
- Datenbereitstellung für Personalverwaltung (XML)
- Emails abrufen (mehrere Konten)
- Emails weiterleiten
- Kundendisplays ansteuern (RS-232)
- Endlos-Bondrucker ansteuern (Papier schneiden, Kassenschubladen öffnen, drucken)

Mehr fällt mir jetzt nicht ein. Aber es wird immer mehr und es war noch nichts darunter, was man nicht anständig mit Python lösen konnte.

Und nicht vergessen sollte man, dass ich auch Programme einsetze, die in Python programmiert wurden, aber nicht von mir.

Z.B.:
- Trac
- Zope
- MoinMoin
- WingIDE

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
ne0h
User
Beiträge: 115
Registriert: Samstag 16. Februar 2008, 11:35

Montag 5. Mai 2008, 20:21

tausend menschen > tausend meinungen > tausend lügen ?
Darum geht es mir eigentlich nicht. Es ist schon klar, dass der alte Spruch gilt: Frag Tausend Menschen und Du erhälst Tausend Meinungen. Trotz dessen ist es m.E. möglich, wenigstens in den Grundzügen die Tendenzen zu erfassen von Entwicklern, die sich tiefer gehend damit beschäftigen.


Hallo gerold,
Was sind Riesenprojekte? Das sind doch meist Projekte, die aus mehreren Programmen bestehen, richtig? Ist ein Projekt das aus mehreren Programmen besteht ein Riesenprojekt, oder sind das mehrere kleine Projekte?
Das meinte ich mit der "Definitionssache". Mir ist selber auch nicht so ganz klar, wie ich die Einteilung vornehmen würde. Für mich verschwimmen die Grenzen da sehr schnell.

- Kaffeemaschinen ansteuern (RS-232)
- Kaffeemühlenkontrolle (RS-232)
Das sind zwei sehr unkonventionelle Punkte, aber schön zu sehen, wie vielseitig man doch sein kann. :wink:

Es ist schon beeindruckend, was Du da auf die Beine stellst und noch mehr beeindruckt mich, welches breite Spektrum alleine mit Python abgedeckt wird (in Deinem Fall).

Dahingehend eine Frage: In wie weit spielen andere Sprachen eine Rolle in Deinen Projekten?

Oder besser ausgedrückt: Könntest Du einen geschätzten Prozentsatz nennen, der beziffert, zu welchen Anteilen andere Sprachen in Deine Entwicklung mit einfließen? Also z.B.:

Bestellwesen - 80% Python und 20% C/C++

Nicht für jeden Deiner Punkte, mir gehts nur ganz grob um eine Einschätzung Deinerseits und die subjektive Verteilung.


Gruß

ne0h
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 5. Mai 2008, 20:53

Hallo ne0h!
- Kaffeemaschinen ansteuern (RS-232)
- Kaffeemühlenkontrolle (RS-232)
Da fällt mir ein, dass ich "Schankanlagensteuerung" vergessen habe. :-) Ist zwar leider nicht mehr im Einsatz, aber funktionierten tut's.
ne0h hat geschrieben:Dahingehend eine Frage: In wie weit spielen andere Sprachen eine Rolle in Deinen Projekten?
- Point of Sale (Kassensysteme)

Das Kassensystem wurde ursprünglich mit Visual Basic 6.0 programmiert. Ich arbeite nebenbei daran, dieses Monster nach Python zu portieren. Das kann aber noch Jahre dauern.

- Bestellwesen

Daran sitze ich gerade und werde noch die nächsten zwei Monate voll damit beschäftigt sein. -- Alles Python.

- Computerüberwachung (Fernüberwachung)

Ich habe mehrere (Python-)Tools, welche ich per SSH (Windows/Cygwin, Linux/OpenSSH) aufrufe. Die Daten kommen über STDIN und und werden ausgewertet. Im Hintergrund arbeiten mehrere Threads, die mit Datensammeln beschäftigt sind und im Vordergrund wird der Status der überwachten Computer (Speicher, Auslastung, Festplatten, ...) angezeigt.
Also SSH ist nicht in Python programmiert, wenn du das meinst.

- Daten von und an Mikrocontroller empfangen und schicken (RS-232)

Also, die Daten werden über die RS-232-Schnittstelle an Mikrocontroller geschickt und werden über die RS-232 empfangen. Die Mikrocontroller selber (Atmel AVR) werden mit Bascom (BASIC) programmiert. Es gäbe zwar auch die Möglichkeit, diese Mikrocontroller mit Python zu programmieren, aber Bascom ist ausgereifter. Ernsthafte Programme habe ich damit noch keine erstellt. Das ist mehr ein Hobby von mir.


Wenn man das alte Kassenprogramm weg lässt, dann würde ich behaupten, dass die Mischung aus 80 % Python, 10 % SQL, 5 % Bash, 4 % JavaScript und 1 % Bascom besteht. Python spielt dabei seine Stärke als Glue-Language voll aus.

mfg
Gerold
:-)
Zuletzt geändert von gerold am Montag 5. Mai 2008, 20:58, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
lunar

Montag 5. Mai 2008, 20:55

my 2 (or more) cents

Shell-Skripting ist Python üerblegen, wenn eine Aufgabe viele externe Tools erfordert, die das Gros der Arbeit erledigen, aber kaum eigene Logik implementiert. Sowas beispielsweise, was eigentlich nur ein größeres "Alias" für eine Handvoll hintereinander auszuführender Programme darstellt. Python stünde hier trotz seiner klaren Syntax einfach im Weg, weil das Aufrufen von Unterprozessen einfach ein Tick komplexer ist als in bash.

Zudem ist CPython ungeeignet für Aufgaben, die einen hohe Grad der Parallelisierung erfordern, wie beispielsweise hochkomplexe numerische Simulationen. Hier kollidieren die Grenzen von Pythons Architektur - insbesondere der GIL - und fehlende Optimierungen im Interpreter mit den Ansprüchen der Entwickler. Abgesehen davon, dass der GIL die Ausführung eines Python-Programms auf mehreren Kernen ziemlich behindert, fehlen dem Interpreter bzw der Standardbibliothek für dieses Aufgabenspektrum erforderliche Goodies wie automatische Schleifenparallelisierung, parallelisierte Container-Klassen und so weiter.

Sonst sehe ich außer den üblichen Verdächtigen (Kernelmodule, Treiber, Mikrocontroller, Embedded, etc.) keine Grenzen für Python, obwohl ich persönlich bei manchen Aufgabenfeldern Zweifel hinsichtlich der Performance von Python habe. Ich glaube einfach nicht, dass ein DBMS in Pure Python die selbe Performance erreichen würde wie Postgre oder gar Oracle.

Allerdings ist das ein Glaube, der sowohl bewiesen als auch entkräft werden kann. Gentoos Paketmanager sind hier ein schönes Beispiel: Paludis (C++) ist genauso langsam wie Portage (Python), pkgcore (Python) ist zwar schnell, aber anscheinend nur, weil die Entwickler extrem strenge Code-Richtlinien haben (Exceptions sind verpönt), und sogar os.path in C neu geschrieben haben.

Für "Riesen"-Projekte ist Python eigentlich gut geeignet, das geht sogar so weit, dass das von Java gehegte und gepflegte Over Engineering gerade im Web-Bereich (dem Entwickler droht nicht die Hölle, sondern **J2EE** ;) ) den Sprung nach Python geschafft hat (J2EE + Python = Zope). Da hätte ich auch gleich noch was, wofür ich Python nie einsetzen würde: Um damit Zope-Webanwendungen zu schreiben. Das allerdings liegt jetzt eher an Zope als an Python ;) (nichts für ungut Gerold ;) )
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 5. Mai 2008, 21:11

lunar hat geschrieben:Da hätte ich auch gleich noch was, wofür ich Python nie einsetzen würde: Um damit Zope-Webanwendungen zu schreiben. Das allerdings liegt jetzt eher an Zope als an Python ;) (nichts für ungut Gerold ;) )
Hallo lunar!

Ich verstehe dich. Auch ich schreibe kleine und mittlere Webanwendungen nicht mehr mit Zope, sondern (in meinem Fall) mit CherryPy und Cheetah. Aber wenn ich ein Content Management System brauche, dann verwende ich Plone. -- Es gibt einfach noch nichts, im Python-Bereich, was Plone den kleinen Finger reichen könnte. Das letzten Plone-Projekt, bei dem ich auch meine Finger im Spiel hatte, war im September 2007 --> http://sw3.at/ Also viel läuft im Moment nicht mit Plone.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
lunar

Montag 5. Mai 2008, 21:18

Naja, Plone ist jetzt nicht unbedingt gleich Plone. Sicher, Plone kann man erweitern und dafür programmieren, aber in erster Linie ist es ja immer noch eine *fertige* Webanwendung, die prinzipiell ohne große Veränderungen eingesetzt werden kann. Plone ist ein super CMS, aber als Admin einer CMS-Seite wird man ja auch nicht direkt mit Zope konfrontiert. Als armer, unschuldiger Webentwickler kriegt man dagegen die volle Dröhnung Zope ab, nicht jeder überlebt das ;)
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 5. Mai 2008, 23:07

lunar hat geschrieben:Allerdings ist das ein Glaube, der sowohl bewiesen als auch entkräft werden kann. Gentoos Paketmanager sind hier ein schönes Beispiel: Paludis (C++) ist genauso langsam wie Portage (Python), pkgcore (Python) ist zwar schnell, aber anscheinend nur, weil die Entwickler extrem strenge Code-Richtlinien haben (Exceptions sind verpönt), und sogar os.path in C neu geschrieben haben.
Das liegt aber auch daran, dass der Portage-Tree eine dumme Struktur zum verarbeiten ist, wenn man Performance haben will.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
ne0h
User
Beiträge: 115
Registriert: Samstag 16. Februar 2008, 11:35

Dienstag 6. Mai 2008, 09:18

@gerold
Wenn man das alte Kassenprogramm weg lässt, dann würde ich behaupten, dass die Mischung aus 80 % Python, 10 % SQL, 5 % Bash, 4 % JavaScript und 1 % Bascom besteht. Python spielt dabei seine Stärke als Glue-Language voll aus.
Diese "Glue-Language" Bezeichnung hört man relativ oft, wenn es um Python geht. Insofern liegt die Stärke Deiner Meinung nach also darin, mit verschiedensten Implementierungen und Erweiterungen aus anderen Sprachen zurecht zu kommen?


Interessant finde ich die Computerüberwachung, wobei ich da nicht alles verstanden habe (z.B. was das STDIN betrifft. Wie genau werden die Daten an python übergeben?)

Aber durchaus ein sehr interessantes Spektrum Deiner Aktivitäten. :wink:


@lunar
Zudem ist CPython ungeeignet für Aufgaben, die einen hohe Grad der Parallelisierung erfordern, wie beispielsweise hochkomplexe numerische Simulationen. Hier kollidieren die Grenzen von Pythons Architektur - insbesondere der GIL - und fehlende Optimierungen im Interpreter mit den Ansprüchen der Entwickler. Abgesehen davon, dass der GIL die Ausführung eines Python-Programms auf mehreren Kernen ziemlich behindert, fehlen dem Interpreter bzw der Standardbibliothek für dieses Aufgabenspektrum erforderliche Goodies wie automatische Schleifenparallelisierung, parallelisierte Container-Klassen und so weiter.

Sind das nicht gerade jene Bereiche, in welchen C/C++ die Teile der Berechnungen übernimmt und Python auch wieder als "Brücke" dient, mittels welcher die weiter Verarbeitung stattfindet?

Sonst sehe ich außer den üblichen Verdächtigen (Kernelmodule, Treiber, Mikrocontroller, Embedded, etc.) keine Grenzen für Python...
Hm, viell. verstehe ich es falsch, aber Python ist doch gerade im Ebedded Bereich gern gesehen (wie bei OpenOffice, Blender, etc.) oder?



Gruß

ne0h
Benutzeravatar
Masaru
User
Beiträge: 425
Registriert: Mittwoch 4. August 2004, 22:17

Dienstag 6. Mai 2008, 09:33

ne0h hat geschrieben:... Hm, viell. verstehe ich es falsch, aber Python ist doch gerade im Ebedded Bereich gern gesehen (wie bei OpenOffice, Blender, etc.) oder? ...
Die Skriptsprachenintegration ist nichts ja nichts neues, und Du siehst es auch ganz richtig: es *wird* gerne gesehen.

Die Grundfunktionalitäten in diesen Produkten (Blender, Gimp, Panda3D, OpenOffice ...) sind jedoch IMO nicht in/mit Python realisiert.

Man kann mit Python z.B. in den unterstützen Grafikanwendung customized Filter und komplexere Abfolgen automatisieren. Jedoch wird jeder, der mal versucht hat ein Blender-Skript zu schreiben merken, dass dies nicht gerade ein "performante Angelegenheit" ist. Aber gerade das ist ja nun auch nicht gerade ein Punkt, nach dem man im Bereich der 4-12h Renderzeiten-Branche fragen würde ;).

>>Masaru<<
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Dienstag 6. Mai 2008, 09:41

ne0h hat geschrieben:
Sonst sehe ich außer den üblichen Verdächtigen (Kernelmodule, Treiber, Mikrocontroller, Embedded, etc.) keine Grenzen für Python...
Hm, viell. verstehe ich es falsch, aber Python ist doch gerade im Ebedded Bereich gern gesehen (wie bei OpenOffice, Blender, etc.) oder?
Du verstehst da Embedded falsch. Du meinst eingebettet als Skriptsprache in andere Programme, Lunar meint hingegen eingebettet als Steuerung kleiner Geräte wie Toaster, Messaparaturen etc.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
ne0h
User
Beiträge: 115
Registriert: Samstag 16. Februar 2008, 11:35

Dienstag 6. Mai 2008, 10:08

@masaru


Ok, danke für die Erklärung.



@Leonidas

Lunar meint hingegen eingebettet als Steuerung kleiner Geräte wie Toaster, Messaparaturen etc.

Steht das nicht im Widerspruch zu gerolds Kaffeemaschinensteuerung? :wink:


ne0h
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 6. Mai 2008, 10:34

ne0h hat geschrieben:Diese "Glue-Language" Bezeichnung hört man relativ oft, wenn es um Python geht.
Hallo ne0h!

Brauche ich Datenbankzugriff, dann importiere ich ein (DB-API 2)Modul, welches mir Zugriff auf die Datenbank gewährt. Gibt es für diese spezielle Datenbank kein eigenes Modul, dann gibt es wahrscheinlich einen ODBC-Treiber dafür. Also importiere ich ein ODBC-Modul, welches mir Zugriff auf alle ODBC-Treiber gibt.

Brauche ich eine grafische Oberfläche, dann importiere ich wxPython und erstelle mir damit die Fenster und Dialoge die ich als Schnittstelle zum Menschen brauche. Mit wxPython kann man nicht nur GUIs erstellen. Man kann damit auch drucken und Pfade zu Konfigurationsdateien herausfinden. Man hat damit auch ein feines Konfigurationssystem (INI-ähnlich) zur Verfügung. Umwandeln, skalieren und verändern von Bildern ist damit auch möglich. Oder das Abspielen von Soundfiles.

Nehmen wir als anderes Beispiel das Umwandeln einer MP3-Datei nach OGG. Für so etwas gibt es kein fertiges Python-Modul. Also sucht man sich eine Bibliothek die so etwas kann. Ist diese Bibliothek in C geschrieben, dann kann man diese über *ctypes* direkt einbinden. Es ist zwar ein wenig Arbeit, herauszufinden wie man die DLL ansprechen kann, aber es geht. Hat man die Zeit dazu nicht oder fehlt das Wissen dafür, dann kann man fertige Kommandozeilenprogramme aus Python heraus aufrufen. Man sucht sich also so ein Kommandozeilenprogramm das die Aufgabe erfüllen kann. Dieses ruft man z.B. mit *subprocess* auf. Dabei kann man Kommandozeilenparameter übergeben. Man kann an das Programm Daten sogar während der Laufzeit übergeben. Diese werden nach STDOUT (z.B. mit print) geschrieben (wie das Schreiben in eine Datei). Das andere Programm übernimmt diese Daten über dessen STDIN (wie das Lesen aus einer Datei). Wenn das andere Programm etwas nach dessen STDOUT schreibt, dann kann man das in Python über die eigene STDIN einlesen.
Man kann also andere Programme aufrufen, als ob sie zum eigenen Programm dazugehören.

Python kann die Schnittstelle zwischen mehreren Programmen, Datenbanken und GUIs sein. Es kann Daten vom Internet holen und auch wieder zurück schicken. Es kann XMLRPC-Server und auch Client sein. Da Python so vielseitig ist, kann man es wie einen Kleber einsetzen der alles zusammenhält (Glue-Language). Ideal für große und rießige Projekte um einzelne hochspezialisierte Detailaufgaben zu einem Ganzen zusammenzufügen.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
BlackJack

Dienstag 6. Mai 2008, 10:37

@ne0h: Die Kaffeemaschine wird ja von aussen gesteuert, das Python-Programm läuft nicht auf der Maschine. *Dann* wäre es eingebettet.

@gerold: MP3→OGG sollte mit vorhandenen Modulen möglich sein. Anbindung an die `libmad` zum dekodieren und die Vorbis-Bibliotheken zum enkodieren gibt es für Python. :-)
Antworten