Das deutsche Python-Forum

@modelnine:

Vielleicht solltest du mal etwas genauer lesen bevor du hier anfängst andere Leute (mich) zu beleidigen. Wenn ich die Aussage, dass Python genauso viel kann wie C++ für absolut falsch HALTE ist das wohl meine Meinung die mir zusteht. Ob sie dir gefällt oder nicht ist mir da total egal. Ich lasse mir bestimmt nicht von dir vorschreiben wie ich hier was zu schreiben habe.

Fakt ist, dass ich mit Python NICHT alles machen kann was ich auch in C++ tun kann, was allein schon daran scheitert, dass Python eine SCRIPTSPRACHE ist. Du hast doch selbst geschrieben, dass das Message Handling zwischen Threads in Python eher umständlich ist. Mit anderen Worten es geht nicht so wie in C++! Sicher kann man alles irgendwie hinbekommen, aber manchmal gibt es einfach Grenzen an die Python stößt.

Beispiele? BITTE:
- registrierte COM Schnittstelle in Windows (die also aus der Registry gestartet wird) unmöglich!
- zugriff auf Sapi4 - unmöglich! (Auch ein Jahr Forschung hat da nichts anderes ergeben. Es wird immer eine dll benötigt.)
- gleichzeitig Thread, Klassen und Dateiübergreifendes Eventhandling, wenn überhaupt möglich, extrem kompliziert.
- schon mal was von Assembler Programmierung mit Python gehört? - ich nicht!
- usw usw usw

Ich will hier Python nicht schlecht reden, das liegt mir fern. ich bin begeistert von Python, da dadurch die Entwicklung wesentlich schneller geht. Aber meiner Meinung nach ist es halt einfach nicht richtig, dass in Python alles geht. Lasse mich da gern vom Gegenteil überzeugen, nur beleidigen lasse ich mich nicht so gern!

Ach so, da du Modelnine dich ja selbst als der Messias in Python darstellst beantworte mir doch einfach mal ein paar meiner Python Fragen die mir hier im Forum komischerweise niemand beantworten kann, wie zB:

http://www.python-forum.de/viewtopic.php?p=32878#32878
http://www.python-forum.de/viewtopic.ph ... highlight= <-- hat sich erledigt
http://www.python-forum.de/viewtopic.ph ... highlight=

Das ist sicherlich sinnvoller als deine unglaubliche Intelligenz mit solchen Nichtigkeiten zu belasten wie dir möglichst kreative Beleidigungen auszudenken.

Aber schön, dass mein Statement solch eine Diskussion auslöst, das ist ja wohl auch der Sinn eines Forums. Jeder kann seine Meinung äußern!

Vielleicht solltest du mal etwas genauer lesen bevor du hier anfängst andere Leute (mich) zu beleidigen. Wenn ich die Aussage, dass Python genauso viel kann wie C++ für absolut falsch HALTE ist das wohl meine Meinung die mir zusteht. Ob sie dir gefällt oder nicht ist mir da total egal. Ich lasse mir bestimmt nicht von dir vorschreiben wie ich hier was zu schreiben habe.

Reg Dich ab! Ich hab in meinem ersten Post gesagt dass ich Dich einfach nur darum bitten würde zu sagen dass Du momentan keinen Weg siehst das in Python zu machen, bevor Du hier rumgehst und erzählst dass es in Python oder mit (was für mich auch dazugehört, und ich dachte Diskussionsgrundlage dieses Threads gewesen wäre) Python nicht möglich ist.

Um danz kurz darauf bezug zu nehmen was Du geschrieben hast:

registrierte COM Schnittstelle in Windows (die also aus der Registry gestartet wird) unmöglich!

Da ich selbst kein Windows-Programmierer (und das früher nur relativ unregelmäßig gemacht habe) bin kann ich dazu wenig sagen. Ich hab allerdings schon von Leuten rund um das Py2Exe-Projekt gehört, die genau das hinbekommen haben mittels py2exe. Sprich: ich würd auf der entsprechenden Mailingliste mal nachfragen gehen was sich in die Richtung tut, und man wird Dir sicherlich helfen können, oder aber auch sagen können dass das allgemein nicht geht, oder wie auch immer. Nur: bevor Du einfach sagst, das geht mit Python nicht, guck erst mal nach ob es Erweiterungen gibt die das vielleicht bewerkstelligen können.

zugriff auf Sapi4 - unmöglich! (Auch ein Jahr Forschung hat da nichts anderes ergeben. Es wird immer eine dll benötigt.)

Es gibt für Python ctypes (wir reden von Windows?), was genau das macht: nämlich eine DLL an Python anzubinden. Sprich: wenn Du einfach mit ctypes einen Wrapper (in Python!) schreibst, dann kannst Du das SAPI ganz normal auch von Python ansprechen. Nur weil eine solche Bibliothek nicht in den Batteries-Included ist heißt das noch lange nicht dass es nicht mit Python geht, zum Beispiel eben über ctypes.

gleichzeitig Thread, Klassen und Dateiübergreifendes Eventhandling, wenn überhaupt möglich, extrem kompliziert.

Da ich erstens nicht so ganz verstehe was Du machen willst, da die Termini in der Kombination für mich absolut nichtssagend sind, und zweitens es auch nicht richtig ist dass Eventhandling in Python nicht geht (ich erinnere nur an pywin32 mit WaitForMultipleObjects.*, oder aber Queue.Queue zur Thread-Kommunikation), kann ich dazu nur sagen: das was Du machen willst geht anscheinend (und das ist häufig so) so wie Du's in C++ machen willst in Python eben nicht. Dafür gehts in Python auf anderen Wegen. Wenn Du die Problematik ein bisschen genauer beschreiben würdest könnte ich da wahrscheinlich (wenn's sich um allgemeine Dinge handelt) auch weiterhelfen, nur meine Ahnung von Windows hält sich arg in Grenzen.

Jede Sprache hat ihre Idiome, und aus meiner Sicht ist es leider so dass Du entweder die Python-Idiome nicht magst weil sie mit den C++-Idiomen kollidieren die Du so kennst, oder aber schlicht und ergreifend die Python-Idiome nicht kennst.

schon mal was von Assembler Programmierung mit Python gehört? - ich nicht!

Natürlich. Schon mal was von PyRex, PyC, psyco (im Endeffekt auch Assembler durch Python), oder auch von PyASM gehört? Wenn's Dich interessiert poste ich gerne Links. Zur Not schreib ich auch eine kleine Python-Erweiterung, das ist dann zwar nicht mehr pures Python, aber die Logik meines Programms liegt trotzdem noch in Python mit ungefähr 20 Zeilen C irgendwo.

Das war eigentlich auch der Stein der meine Antwort ins Rollen gebracht hat: die Dinge die Du bisher angesprochen hast gehen mit purem Python vielleicht teilweise nicht, mit Erweiterungsmodulen aber schon, zur Not auch mit eigenen, aber die Erweiterung beschränkt sich in meinem bisherigen Programmierrahmen immer auf ungefähr 20 Zeilen. Oder sie gehen eben auf anderen Wegen als Du es aus anderen Sprachen gewohnt bist. Jede Sprache hat ihre eigenen Idiome. Und es steht Dir frei zu sagen dass Du die Python-Idiome für viele Dinge nicht magst, es ist aber aus meiner Sicht eben nur inflammatorisch zu sagen dass die Dinge deswegen prinzipiell mit Python nicht gehen, weil sie's eben schon tun, nur manchmal mit ein bißchen Hilfe.

Ach so, da du Modelnine dich ja selbst als der Messias in Python darstellst beantworte mir doch einfach mal ein paar meiner Python Fragen die mir hier im Forum komischerweise niemand beantworten kann, wie zB:

... Ganz viele Fragen die mit Windows-Spezifika zu tun haben. Ich hab, wie ich oben auch schon bemerkte, von Windows-Programmierung wenig bis keine Ahnung, deswegen lass ich selbst die Finger davon. Unabhängig davon: ich hab mich niemals als der Python-Messias dargestellt. Ich hab Dich nur gebeten Deine Aussage zwecks der Benutz- und Einsetzbarkeit etwas zu präzisieren (oder sie sein zu lassen), da Deine Aussage sehr, sehr allgemein war, das man nämlich diese Dinge nicht in Python machen kann ist einfach nicht wahr.

So. Falls Du Dich beleidigt gefühlt hast tut es mir leid, darum gings mir nicht (und Du hast recht dass ich manchmal die falschen Worte finde um das auszudrücken, ich hab selbst eben noch mal meinen letzten langen Post gelesen und der war auch nicht ganz sauber). Es ging mir darum dass ich für meinen Teil Deine Aussage zu allgemein empfand, und ich hab oben noch mal dargelegt was meine Ansicht war/ist dazu.

ok ok, abgeregt - das Wort Troll hat mich nur etwas "angepisst"


wie ich es schon in meinem letzten Beitrag gesagt habe, ist alles irgendwie mit Umständen machbar. Allerdings nicht so, wie Python ursprünglich mal gedacht war. Es ist wahrscheinlich richtig, dass man mittels Py2Exe einen dauerhaft registrierbaren COM Server bauen kann, aber dann habe ich eine kompilierte exe und das ist nicht der Sinn von Python.

Mit dem Assembler, hab ich wirklich noch nie was von gehört.

Sapi4: Richtig, eine gewrappte dll und schon kann ich mit Python auf die Sapi4 zugreifen. Genau so mache ich (bessergesagt wir) es auch. Nur diese dll ist mit C++ geschrieben und nicht mit Python. (Vielleicht hab ich da auch noch nie was von gehört, dass man mit python auch dll's schreiben kann)

Mein Event Problem: manchmal verstehe ich mich selbst nicht mehr...
quasi 3 involvierte Dateien:
- eine zur Anbindung an die COM Schnittstelle von xy
- eine die Ausgaben der COM xy braucht
- ein COM Server der die erste mit der zweiten verbindet.
die Kommunikation zwischen diesen dreien gestaltet sich als sehr komplex, da man am Rande erwähnen sollte, dass es von der 1. Datei ca 4 gibt und von der zweiten beliebig viele (Momentan 5) und dazu noch der COM Server aus 3 Klassen besteht die jeweils im gesamten Programmablauf nur einmal initialisiert werden dürfen aber trotzdem auch untereinander kommunizieren müssen. Alles verzwickt. Um das vernünftig und verständlich zu beschreiben, müsste ich wahrscheinlich mehrere Seiten beschreiben, aber auch Informationen preis geben, die ich jetzt noch nicht preisgeben möchte.

Buell hat geschrieben:Sapi4: Richtig, eine gewrappte dll und schon kann ich mit Python auf die Sapi4 zugreifen. Genau so mache ich (bessergesagt wir) es auch. Nur diese dll ist mit C++ geschrieben und nicht mit Python. (Vielleicht hab ich da auch noch nie was von gehört, dass man mit python auch dll's schreiben kann)

Aber genau das ist doch das schöne an Python, das man es mit C++ erweitern kann. Somit kann man indirekt (fast) alles mir Python machen... Das man mit Python selber keine DLLs schreiben kann, dürfte wohl klar sein.

Klar ist, das man mit C mehr machen kann, als mit Python. Aber mit welchem Aufwand? Unterm Strich ist Python einfach effektiver in der Programmierung. Noch mehr als in C kann man wahrscheinlich mit Assebler machen, aber das dürfte nochmal um einiges Aufwändiger sein... Mal eben einen Test-CGI-Webserver starten, in C oder Asselbler?

Und das sind halt die wahren stärken, das man einfach schneller ans Ziel kommt und das ganze auch noch überschaubarer ist... Die Batteries-Included sind einfach genial...

jens hat geschrieben:Aber genau das ist doch das schöne an Python, das man es mit C++ erweitern kann. Somit kann man indirekt (fast) alles mir Python machen... Das man mit Python selber keine DLLs schreiben kann, dürfte wohl klar sein.

Das Problem dürfte sich eigentlich mit Ironpython auch erledigt haben, oder

Clython hat geschrieben:

jens hat geschrieben:Das man mit Python selber keine DLLs schreiben kann, dürfte wohl klar sein.

Das Problem dürfte sich eigentlich mit Ironpython auch erledigt haben, oder

Oder evtl. mit http://wiki.python.de/PyPy

Python Master 47 hat geschrieben:So Leute,

Dieser Test sagt dann wohl alles!

Der Test sagt gar nichts.

Eine sprache ist nicht dann besser wenn sie mehr features hat. Sonst könnte ich auch ein Auto entwickeln das eine fritöse, eine microwelle eine Waschmaschiene und einen Trockner mit einbaut und es auf einer "Vergleichsseite" mit Mercedes vergleichen und mein Auto als besser darstehen lassen

*ich liebe einfach die autovergleiche *

Wenn ich weiter hinein gehe sehe ich z.b: http://www.digitalmars.com/d/declaration.html#alias

Nun sie sehen es als Vorteil das D typ aliase zu erstellen. Ich sehe das als kompletten nachteil. Code wird komplett unleserlich wenn mann es erlaubt das ein int datentyp ein alias auf etwas komplexeres ist.


Resizeable arrays
Part of the standard library for C++ implements resizeable arrays, however, they are not part of the core language. A conforming freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide these libraries.

Nun C#, C++, Java bringen alle Dinge wie java.util.ArrayList mit. C# nennt die Klasse ebenso ArrayList, bei C++ finden sich die Listen ebenso in der std.
Um beim beispiel in Java zu bleiben. Ich habe die Möglichkeit mir eine
ArrayList<MyClass> x; zu erstellen welche dynamisch ist. Oder aber ich kann mir ein MyClass[] x; Array erstellen.
Ganz klar ist das ein Array performanter ist, da dem Programmierer obliegt sich darum zu kümmern das noch platz da ist. Sprich mit dem Array kann ich sehr lowlevel arbeiten. Wenn ich der meinung bin ich bräuchte ein Array das sich dynamisch vergrössert, und bin gewillt die geringere Performance zu akzeptieren nehm ich die ArrayList.
Was mach ich unter D?
Ich nehme immer ein dynamisches Array und muss immer mit den performance einbußen leben, auch wenn ich weiss das ich nur max 10 Objecte darin speichern werde und nie die dynamic ausnutze.

Nach deiner Logic dürfte es auch kein Python geben, da mann bei viel mehr "Features" ein Grünen Kasten unter Perl machen könnte
Die vielen Möglichkeiten in Perl etwas zu tun sind aber nach der meinung vieler genau der Grund weshalb sie sich nie auf Perl einlassen wollen.
Ich bin sogar der Meinung das mann sowenige Möglichkeiten in eine Sprache einbauen sollte wie möglich ohne die Funktionalität einer Sprache einzuschränken.
Die Komplexität in der Programmierung wird schon jetzt durch viele Formate, Protokolle, Systeme hochgetrieben, eine Sprache mit verschiedenen Arten zu programmieren soll da einen nicht noch weitere Steine in den Weg werfen.
Ich mag Python gerade deshalb weil ich schnell auch fremden Code lesen kann da sich die Art und Weise wie er geschrieben wurde nicht von meiner Unterscheidet.

Eine interessante Gegenüberstellung von gängigen Programmiersprachen wie Python, Perl, Java und C++ findet man auf folgender Seite:

http://furryland.org/~mikec/bench/

Ich habe schon selber in C/C++ programmiert und ich kann nur sagen, dass Python wirklich Balsam auf der Seele eines Programmierers ist. Besonders die Klammersetzung und die Setzung des Semikolon ... ein Grauen bei C/C++. Da bleib ich doch lieber bei Python...
Wenn du von Python aus, C oder C++ lernen willst, rate ich Dir mit C++ anzufangen, allein der Möglichkeiten wegen. So bietet C++ mehere Datentypen, sowie auch die Möglichkeit der objektorientierten Programmierung (Klassen, Vererbungen, Assoziationen, Kompositionen,...). Außerdem die Möglichkeit von virtuellen Funktionen, Überladen von Operatoren,...

Gruss,
Toni

Ja werd ich auch so machen!

Ehrlich gesagt, gefällt mir Python auch besser, hab mir mal n paar C/C++ Codes angeschaut und die Syntax ist im Vergleich zu Python grausam!

Toni83 hat geschrieben:Besonders die Klammersetzung und die Setzung des Semikolon ... ein Grauen bei C/C++.

Das hab ja auch einige andere Sprachen... Was ich aber nicht verstehen kann ist warum? Für mich sind das uralte Relikte aus vergangenen Zeiten Wobei Basic das auch nicht hatte. Python mit seiner Einrückung ist IMHO die beste Lösung zur bildung von Blöcken

Es wäre doch auch denkbar, eine Zwischenschicht in C++ und Co. einzufügen! So das man Blöcke, wie bei Python einrücken kann und man Semikolon nur dann braucht, wenn man mehrere Befehle in einer Zeile haben will. Die Zwischenschicht übersetzt das dann wieder in die dolle Klammersetzung der original Sprache, bevor der Compiler angeworfen wird... Sowas wie ein precompile Das alles könnte man wahrcheinlich recht schnell in Python implementieren, denke ich... Warum ist da noch keine auf die Idee gekommen? Oder gibt es sowas schon?

Humm... Das was Du vorschlägst ist durchaus möglich, bloß hat Klammersetzung als Block-Delimiter auch noch andere Konsequenzen, wie zum Beispiel dass Blöcke sehr einfach geschachtelt werden können, auch in Ausdrücken, siehe da in Python das lambda-"Krüppelkonstrukt."

Python hat eigene Wege entwickelt um mit den Limitierungen die eine einrückungsbasierte Grammatik mit sich bringt umzugehen (siehe zum Beispiel Guido's vorschlag keine unbenannten Blöcke mehr zuzulassen, sondern nur noch def()s), und ich wage zu bezweifeln dass man so eine Grammatik ohne Einschränkungen für den gängigen C++-Funktionsumfang aufstellen könnte. Sprich: wenn man probiert die Python Grammatik auf C++ abzubilden ginge das schon, bloß verliert man dann sehr viel von dem was C++ auszeichnet.

Die Syntax von C++ ist einfach zu "verworren". Zum Beispiel kann die Platzierung eines Semikolons darüber entscheiden ob etwas eine Deklaration oder eine Definition ist.

Nur um nochmal eine andere Meinung in den Ring zu werfen: Ich würde von Python ausgehend erst einmal C lernen. C++ kann durch seine Komplexität sehr schnell frustrierend werden, während C, genau wie Python, eine syntaktisch und semantisch eher schlichte und einfache Programmiersprache ist.

Jetzt wollte ich wissen, was ich mit C/C++ machen kann, was in Python nicht geht!

Alles, wofür man in Python externe systemnahe Module benötigt, die aber noch nicht geschrieben sind.

Die Vorteile von C/C++ sehe ich darin, daß man nicht überall einen Interpreter oder Teile davon rumschleppen muß, sondern Standalone-Anwendungen produziert, die auch noch schön schnell sind.
Außerdem sind Windows und Linux in C/C++, meist wohl nur in C, geschrieben, ebenso die meisten Standardanwendungen.
C/C++ ist also die Sprache der Profis, die jedenfalls der zahlende Anwender erwartet.
Wenn es nur nicht so elendig schwer / unpraktisch wäre.
Hier schon mal ein gutes Buch zu C (vom Autor online gestellt, kostet auf Papier 44,95 EUR):

http://courses.iicm.edu/the_c_book/CD-ROM/

Also, ich versuche mit C weiterzukommen, das Problem ist nur, für die kleinen Sachen, die ich so programmiere (z.B. Berechnungen zur Buchführung), genügen Python, bzw. Perl und liefern schnell sehr brauchbare Ergebnisse.
Python/Perl sind in C geschrieben. Es handelt sich also gewissermaßen um Aufsätze auf C/C++, die einem um den Preis geringerer Geschwindigkeit und Systemnähe, die Programmierung erleichtern.
Bitte sieh Dir einmal diesen Artikel über Perl an, der entsprechend auch für Python gelten dürfte:

http://www.perl.com/pub/a/2001/06/27/ctoperl.html

Im Prinzip verführen Perl und Python einen also, seiner Bequemlichkeit nachzugeben.
Leider machen sie das sehr gekonnt und mit guten Ergebnissen.
Aber C/C++ sind trotz allem eigentlich "the real thing".

Viele Grüße

Aber C/C++ sind trotz allem eigentlich "the real thing".

Das ist eine (ziemlich undifferenzierte) Meinung, keine Tatsache.

Ich könnte, wenn ich wollte, mal wieder einen Beitrag dazu schreiben warum das (nicht nur) aus meiner Sicht höchstgradiger Unsinn ist eine Sprache als "the real thing" zu bezeichnen (und dazu noch zu sagen dass ein Anwender C/C++ erwartet, dem ist das völlig schnurz worin sein Programm geschrieben ist, hauptsache es tut das was er will), aber ich hab heute abend keinen Bock mehr dazu. Vielleicht kann ja der Poster mal nach Beiträgen von mir in diesem Thread suchen, und dann seine Meinung etwas differenzierter darlegen.

und dazu noch zu sagen dass ein Anwender C/C++ erwartet, dem ist das völlig schnurz worin sein Programm geschrieben ist, hauptsache es tut das was er will

Das dürfte interessant werden, wenn man dann mal eine Anwendung schreibt, die man verkaufen möchte:

Anwender: "Wo ist setup.exe ?"
Entwickler: "Das Programm ist in Python geschrieben. Du mußt den Python-Interpreter installieren, das sind nur > 20 MB."
Anwender: "Interpreter ? Für ein 200 K-Skript ? Mach ich nicht. Gib mir setup.exe !"
Entwickler: "Na gut. Ich pack Dir das in einer ausführbaren Datei zusammen."
ActiveState: "Moment. Da habe ich auch noch ein Wörtchen mitzureden."
Py2exe-Entwickler: "Ich auch." (So jedenfalls bei Perl (Perl2exe ist nicht frei)).
Python-Entwickler: "Soso, Du willst Geld auf der Grundlage unserer jahrelangen freien Interpreter-Entwicklung machen ? Schäm Dich was."
Anwender: "Wieso sehen die Fenster so komisch aus ?"
Entwickler: "Ich hab Tk benutzt."
Anwender: "Tk ? Kenn ich nicht. Braucht man nicht. Windows liefert doch Fenster mit."
Entwickler: "Ja schon. Aber wirklich flexibel könnte man die nur über die Windows-C-API ansprechen."
Anwender: "Programmfunktion xy funktioniert nicht immer richtig."
Entwickler: "Ähh, das liegt an Zusatzmodul z. Über das habe ich nicht wirklich die Kontrolle. Ich spreche es nur an."
Anwender: "Und warum reagiert das alles so langsam. Warum benutzt du kein C ?"
Entwickler: "Weil ich meinen Speicher nicht selbst verwalten kann, bzw. will."
Anwender: "Dann lern das erstmal, bevor ich Geld bezahle."

So ähnlich erging es mir jedenfalls mit meinen kleinen Perl-Entwicklungen, die unter anderem aus diesen Gründen frei sind.

Gruß

Hi abgdf!

Alles was ich jetzt schreibe, gilt nur für Windows. Unter Linux sieht die Sache teilweise anders aus.

abgdf hat geschrieben:Anwender: "Wo ist setup.exe ?"

Das stimmt. Die Anwender wollen ein Setup. Ist ja auch verständlich, da nicht jeder weiß wie man ins Startmenü eine Verknüpfung legt oder einfach nur zu faul dafür ist. Ich liefere schon lange kein Programm mehr ohne Setup aus. Alleine schon weil ein Setup professioneller aussieht. Das Setup ist zum Glück keine große Hexerei mehr. Mit InnoSetup ist das in wenigen Minuten erledigt.

abgdf hat geschrieben:Entwickler: "Du mußt den Python-Interpreter installieren, das sind nur > 20 MB." [...] "Na gut. Ich pack Dir das in einer ausführbaren Datei zusammen."

Entweder man erledigt das mit dem Setup oder man macht das Skript direkt ausführbar. Das Installieren des Interpreters und eventuell noch zusätzlicher Module -- das sieht der Anwender nicht ein. Einzig mit der Begründung, dass ansonsten das Programm viel teurer werden würde, da sich der Programmieraufwand erhöht, kommt man weiter. Aber wer will sich denn ständig verteidigen müssen... Also wie schon geschrieben --> ein Setup muss sein, wenn man professionell wirken möchte.

abgdf hat geschrieben:Entwickler: "Ich hab Tk benutzt."

Das kann man aber wirklich keinem Windows-Benutzer zumuten. Ich verwende Tkinter-Programme unter Windows nur dann, wenn es wirklich nicht anders geht. Tk sieht einfach nur sch.... aus.

abgdf hat geschrieben:Anwender: "Programmfunktion xy funktioniert nicht immer richtig." [...] "Ähh, das liegt an Zusatzmodul z. Über das habe ich nicht wirklich die Kontrolle. Ich spreche es nur an."

Dein Fehler. Das Programm muss funktionieren und es lag in deiner Verantwortung, ob du dieses Zusatzmodul verwendest oder nicht. Einzige Außnahme: Wenn der Kunde dich zu diesem Zusatzmodul gedrängt hat. Aber auch dann musst du den Kunden noch vor oder während der Entwicklung auf etwaige Fehler aufmerksam machen. Wenn ein Kunde zum Tischler geht und einen Kasten haben möchte, der aus 5 mm Fichtenholz gefertigt sein soll, dann **muß** der Tischler dem Kunden mitteilen, dass dieser Kasten nicht stabil sein wird. Hinweispflicht! Erst wenn der Kunde trotzdem 5 mm Fichtenholz verlangt, dann kann der Tischler ohne mögliche rechtliche Folgen den Auftrag annehmen. So ist es auch in der Softwareentwicklung.

mfg
Gerold

abgdf hat geschrieben:

und dazu noch zu sagen dass ein Anwender C/C++ erwartet, dem ist das völlig schnurz worin sein Programm geschrieben ist, hauptsache es tut das was er will

Das dürfte interessant werden, wenn man dann mal eine Anwendung schreibt, die man verkaufen möchte:

Anwender: "Wo ist setup.exe ?"
Entwickler: "Das Programm ist in Python geschrieben. Du mußt den Python-Interpreter installieren, das sind nur > 20 MB."
Anwender: "Interpreter ? Für ein 200 K-Skript ? Mach ich nicht. Gib mir setup.exe !"
Entwickler: "Na gut. Ich pack Dir das in einer ausführbaren Datei zusammen."
ActiveState: "Moment. Da habe ich auch noch ein Wörtchen mitzureden."
Py2exe-Entwickler: "Ich auch." (So jedenfalls bei Perl (Perl2exe ist nicht frei)).
Python-Entwickler: "Soso, Du willst Geld auf der Grundlage unserer jahrelangen freien Interpreter-Entwicklung machen ? Schäm Dich was."

Es ging nicht um Perl sondern um Python. Informier Dich doch bitte vorher über die entsprechenden Python-Tools und deren Lizenzbedingungen, bevor Du so etwas in den Raum stellst.

Anwender: "Wieso sehen die Fenster so komisch aus ?"
Entwickler: "Ich hab Tk benutzt."
Anwender: "Tk ? Kenn ich nicht. Braucht man nicht. Windows liefert doch Fenster mit."
Entwickler: "Ja schon. Aber wirklich flexibel könnte man die nur über die Windows-C-API ansprechen."

Oder mit einem Python-Wrapper um diese API oder einem anderen GUI-Toolkit.

Anwender: "Programmfunktion xy funktioniert nicht immer richtig."
Entwickler: "Ähh, das liegt an Zusatzmodul z. Über das habe ich nicht wirklich die Kontrolle. Ich spreche es nur an."

Das Problem hast Du in C und jeder anderen Sprache auch. Es sei denn Du implementierst alles selbst. Das wird aber wahrscheinlich in noch mehr Fehlern enden.

Anwender: "Und warum reagiert das alles so langsam. Warum benutzt du kein C ?"
Entwickler: "Weil ich meinen Speicher nicht selbst verwalten kann, bzw. will."

Weil es in C nicht schneller laufen würde!? Bei den meisten Programmen ist die CPU damit beschäftigt auf die Eingabe vom Benutzer zu warten. Und man kann kritische Programmteile, und nur die, dann auch in C oder Pyrex implementieren. Das Gegenszenario wäre:

Anwender: "Warum dauert die Entwicklung so lange und ist deshalb so teuer?"
Entwickler: "Weil ich in C programmiere und mich um jedes Detail selbst kümmern muss."

Anwender: "Dann lern das erstmal, bevor ich Geld bezahle."

Genau, lerne erstmal die Möglichkeiten von Python.

Du hast dem Zitat von modelnine übrigens überhaupt nicht widersprochen: Dem Anwender ist es schnurz in welcher Sprache das Programm geschrieben ist, hauptsache es tut was es soll. Wenn es in einer `setup.exe` kommt, "native windows look" hat und ausreichend schnell ist, dann interessiert es ihn höchstwahrscheinlich wirklich nicht ob es in Python geschrieben ist, oder in Scheme, oder Nemerle, oder Io oder Lua oder was auch immer.

Ich hab schon viel gelesen aber das ist mir noch nie untergekommen.

Ich geb auf sowas auch kein weiteres Kommentar ab, möchte nurmal anmerken, dass ich immer froh bin, wenn ich ein Python Programm sehe, weil die Installation sehr schnell abläuft, die Programme klein sind und sie platform unabhängig laufen.

Hi!

Dieses Thema wurde zwischenzeitlich kurz gesperrt, aber auch sofort wieder geöffnet...

Ich bitte weiterhin um produktive Beiträge, ohne andere zu beleidigen.

lg
Gerold

gerold hat geschrieben:Dieses Thema wurde zwischenzeitlich kurz gesperrt, aber auch sofort wieder geöffnet...

Danke. Wollte schon Hand anlegen