Anzeige:
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 19

Thema: Einstiegsfrage bezüglich Python

  1. #1
    Registrierter Benutzer
    Registriert seit
    03.01.2006
    Ort
    Kefermarkt
    Beiträge
    6

    Einstiegsfrage bezüglich Python

    Schönen guten Tag,

    Da ich mit C# als Entwicklersprache für ein Projekt, das ich gerade schreibe, relativ unzufrieden bin oder besser gesagt dem Fakt dass es Windows only ist (Mono kommt auch nicht in Frage) würde ich gerne eine Applikation schreiben, die plattformübergreifend ist - und habe mich als Sprache für diese Aufgabe für Python entschieden.

    Erste Frage:

    Kann man Python als Sprache empfehlen? Bisher wurde ja immer vermittelt dass sie einfach zu lernen sei, mächtig und gut strukturiert. Das Prinzip von Python weiß bislang auch zu überzeugen, aber wenn man von C# kommt, sind doch einige Dinge sehr anders. Von dem her würde ich gerne ein paar fundierte Meinungen hierzu hören.

    if erste_frage.antwort == 'yes':
    Zweite Frage:

    Welcher Editor ist für das Programmieren von Python unter Windows zu empfehlen? Da ich auf meinem Notebook wegen Schulgebrauch nur Windows installiert habe, habe ich hier das Problem, keinen komfortablen GUI-Editor zu besitzen - ich habe gVIM getestet, bin aber nicht unbedingt zufrieden. Zu Hause, unter Kubuntu kann ich mit Kate recht komfortable programmieren, intended blocks und syntax highlighting funktionen sehr gut. Gibt es vergleichbares auch für Windows? IDLE gefällt mir da nicht so sehr. Oder empfehlt ihr es explizit?

    if zweite_frage.antwort == 'yes':
    Dritte Frage:

    Printmedien. Welche Bücher kann man für das Erlernen von Python empfehlen? Ich habe bisher 'Byte of Python' durchgearbeitet, ein sehr interessantes Werk (die deutsche Übersetzung, muss man fairerweise dazu sagen), aber behandelt doch nicht all die Dinge die mich interessieren würde - und auch nicht die Lösung für viele Probleme die ich bei der Umstellung bisher noch habe. Ich wäre für Empfehlungen dankbar, persönlich haben mir die O'Reilly-Bücher zugesagt, Python in a Nutshell als Referenz-Nachschlagewerk und das Python Cookbook als Lernmaterial. Was sagt ihr zu diesen Werken, so ihr sie kennt?


    # end block

    Danke für das Durchlesen dieser Formulierungen und auch vielen Dank im Voraus für jegliche Antwort auf die Fragen.

    mit freundlichen Grüßen

    narcosynthesis.

  2. #2
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    1) Ich denke Python kann man unbedingt empfehlen. Hab zwar damit selber nicht viel mehr gemacht als ein kleines Script, bisher, aber der erste Eindruck war gut und von Leuten die das kennen hab ich bisher auch nur gutes gehört.

    2) Eventuell mal SciTE angucken? Sehr netter Editor, allerdings musst du den auf jeden Fall etwas konfigurieren - die Defaulteinstellungen sind ein bisschen blöd
    Aber die Konfiguration machst du ja nur einmal und gut ist

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  3. #3
    Registrierter Benutzer
    Registriert seit
    03.01.2006
    Ort
    Kefermarkt
    Beiträge
    6
    Oh, SciTE gefällt mir wirklich gut. Danke für diesen Tipp.

    Wenn ich jetzt noch die tausenden Fehler, die ich mit Python mache los werde, bin ich glücklich Danke schon einmal.

  4. #4
    Registrierter Benutzer
    Registriert seit
    21.06.1999
    Beiträge
    677
    Zu grafischen Oberflächen mit wxpython ist kürzlich ein brauchbares Buch ershcienen: Rappin, Dunn: wxPython in Action.

  5. #5
    Registrierter Benutzer
    Registriert seit
    10.10.2005
    Beiträge
    39
    1. kommt ganz drauf an, was du machen willst....
      ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen. es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung. die sprache ist untypisiert und es gibt keinen klaren styleguide, zumindest ist mir noch keiner begegnet. die bibliotheken lassen kein muster bei der namensgebung erkennen. es kann gut sein, dass dein projekt 50 mal gut funktioniert und beim 51. mal abstuerzt, weil du irgendwo 'nen kleinen tippfehler drinnen hast oder eine typueberpruefung vergessen hast.
    2. SciTE wurde ja schon genannt, auch die notwendigkeit der manuellen konfiguration. vor allem sollte man bei den schriften ein "$(font.monospace)" hinzufuegen
    3. ich nutze gerne diese python referenz

  6. #6
    Registrierter Benutzer
    Registriert seit
    03.01.2006
    Ort
    Kefermarkt
    Beiträge
    6
    Zitat Zitat von OpOs Beitrag anzeigen
    kommt ganz drauf an, was du machen willst....
    ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen. es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung. die sprache ist untypisiert und es gibt keinen klaren styleguide, zumindest ist mir noch keiner begegnet. die bibliotheken lassen kein muster bei der namensgebung erkennen. es kann gut sein, dass dein projekt 50 mal gut funktioniert und beim 51. mal abstuerzt, weil du irgendwo 'nen kleinen tippfehler drinnen hast oder eine typueberpruefung vergessen hast.
    Hört sich gar nicht gut an, was du da erzählst, diese Problematiken fallen mir als Laien natürlich nicht sonderlich auf, Typisierung ist schon ein Thema, aber ich muss mich da wohl noch mehr einarbeiten.

    Prinzipiell würde ich einfach gerne eine gute, moderne Sprache verwenden, die plattformübergreifend agiert und trotzdem bei brauchbarer Performance einfach zu erlernen bleibt (Faulheit? Oder doch nur zu viel von PHP gewöhnt?).

    Ruby ist da auch immer noch im Gespräch, aber ob ich von Ruby so viel mehr erwarten kann, es bleibt abzuwarten, was man dazu sagen mag.

    @Christoph: Vielen Dank für die Empfehlung

  7. #7
    Registrierter Benutzer
    Registriert seit
    10.10.2005
    Beiträge
    39
    hab noch nie was in ruby gemacht, hab nur schnell mal bei wikipedia reingeschaut und ich muss sagen... auf den ersten blick sieht's aus wie python in 'ner anderen farbe... kann mich aber auch irren.

    nochmal zu dem obengenannten ein beispiel: stell dir vor du hast in deinem programm folgende zeile:
    Code:
    if a==b:
    die zeile ist syntaktisch korrekt und wird in manchen testfaellen das gewuenschte ergebnis liefern. aber irgendwann kann es sein, dass der ausdruck nich das erwartete resultat liefert und du merkst, dass es eigentlich
    Code:
    if a==b():
    heissen muesste. das mag zwar jetzt laecherlich erscheinen, aber wenn du mal ein groesseres projekt entwickelst, kann dich so ein fehler mehrere stunden suche kosten... vom compiler/interpreter kannst du da keine hilfe erwarten.
    und nochmal zu den typueberpruefungen: auch hier kann ein programm scheinbar fehlerfrei funktionieren. wenn du eine variable als parameter an eine funktion uebergibst, muss das objekt nur die von der funktion aufgerufenen methoden implementieren...
    ich hab mal ein kurzes script geschrieben, welches mehrere statusabfragen taetigen sollte, alles in die datenbank schreiben und 'ne mail rausschicken. das script lief fehlerfrei durch, nur die mail kam nicht. in der db war alles in ordnung, das script hatte also offensichtlich funktioniert. wenn ich nich nebenbei noch admin gewesen waere und zugriff auf die maillogs gehabt haette, haette ich den fehler wohl nich so schnell gefunden. statt eine einelementige liste mit der emailadresse zu uebergeben hab ich nur einen string mit der adresse angegeben. da sowohl listen als auch strings die iteration unterstuetzen, hat der interpreter nichts gemerkt und schoen fuer jeden buchstaben der adresse 'ne mail verschickt...
    die loesung war einfach, von hand 'ne typueberpruefung durchzufuehren

    ich will dir python keinesfalls ausreden. ich nutze es gern, weil man schnell und ohne viel umstaende komplexe programme oder nur kleine scripte schreiben kann. aber wenn du in 'nem team arbeitest und dein programm die kritische groesse ueberschreitet, wirst du fluchen... viel fluchen... hier musst du dokumentieren und zwar mehr als bei den meisten anderen sprachen

    und du benoetigst 'nen editor, der dich bei blockweisen ein- und ausrueckungen unterstuetzt (ich weiss jetzt gar nich, ob scite das kann, aber kate kann's ) mal schnell mit dem vi ueber ssh auf dem webserver in 'nem cgi-script 'nen block mit 'ner if-abfrage zu umschliessen iss 'n laengeres projekt

    wenn gegen C# nur die fehlende portabilitaet steht, warum dann nicht ... java???

  8. #8
    Registrierter Benutzer
    Registriert seit
    25.10.2004
    Beiträge
    819
    Zitat Zitat von OpOs Beitrag anzeigen
    ich finde, die objektorientierung ist lausig implementiert. bei methodenaufrufen musst du immer die objektreferenz mit angeben, auch attribute lassen sich nur ueber "self" ansprechen.
    Das macht aber auch Sinn. In C++ und Java wird "self" ja immer implizit übergeben (dort heisst es this). Da bei Python Variablen nicht deklariert werden, muss die Referenz auf self immer angegeben werden, damit man zwischen (Methoden-)lokalen und Instanzvariablen unterscheiden kann. Desweiteren ist es notwendig, weil du Methoden dynamisch hinzufügen (oder löschen) kannst:

    Beispiel:
    Code:
    class A(object):
      def foo(self):
        print "hier ist foo"
    
    # Klassendefinition ist hier zuende 
    def blabla(self):
      print "Ich rufe mal foo auf"
      self.foo()
    
    def neues_foo(self):
      print "Ich bin der neue Foo"
    
    a = A()
    A.bar = blabla
    a.bar() # Ausgabe: Ich rufe foo auf, hier ist foo
    a.foo() # hier ist foo
    b = A()
    b.foo = neues_foo
    b.foo(); a.foo() # neues foo, foo
    old_foo = A.foo
    A.foo = neues_foo
    a.foo() # neues foo
    old_foo(a) # ruft altes foo auf
    es gibt kein public/protected/private. es gibt zwar eine moeglichkeit, methoden und attribute private zu deklarieren, das iss aber auch nur 'ne hintertuerchenloesung.
    Das stimmt. Das ist per design. Python geht davon aus, das der Programmierer weiss, was er tut und dass er sich an Konventionen hält. Z.B. sind Methoden, die mit einem _ beginnen, Klassenintern und nicht als Teil der API zu betrachten. Wenn man sie aber unbedingt aufrufen will, kann man es tun, sollte sich aber nicht wundern, wenn das Programm mit späteren Versionen der API nicht geht.

    Meistens braucht man auch private nicht, da die Sachen anders gelöst sind.

    Beispielsweise nutzt man in C++ und Java oft getter und setter-Methoden.
    Beispiel
    Code:
    class Kreis {
      private int durchmesser;
      public int getDurchmesser() {
        return durchmesser;
      }
      public void setDurchmesser(int durchmesser) {
        this.durchmesser = durchmesser;
      }
    Wenn man also auf bar zugreifen möchte, muss man mit get/set arbeiten. Der Gedanke dahinter ist einfach: Sollte man irgendwann mal seine Klasse so umschreiben, dass sie mit dem Radius arbeitet, laufen alte Programme wie gewohnt weiter, da man einfach die getter/setter entsprechend anpassen würde. Würde jemand direkt auf umfang zugreifen, wäre ein Wechsel nicht so einfach möglich.

    In Python kann man jedoch den Zugriff auf eine Variable abfangen, so man denn will. Nehmen wir an, die Klasse Kreis hatte früher eine Variable durchmesser, die man einfach benutzen konnte
    Code:
    class Kreis(object):
      def __init__(self):
        self.durchmesser = 0
      def tu_irgendwas(self):
        # hier macht man irgendwas
    k = Kreis()
    k.durchmesser = 4
    k.tu_irgendwas()
    Wenn man nun auf Radius umstellt, macht man
    Code:
    def Kreis(object):
      def __init__(self):
        self.radius = 0
      def get_durchmesser(self):
        return self.radius*2
      def set_durchmesser(self, durchmesser):
        self.radius = durchmesser/2
      durchmesser = property(get_durchmesser, set_durchmesser)
    Ein
    Code:
    kreis.durchmesser = 5
    setzt nun den Radius auf 2,5, alter Code ist weiterhin lauffähig.

    Aus diesem Grund bräuchte man private und co. eigentlich so gut wie nie.

    und es gibt keinen klaren styleguide
    Und ob!
    Style Guide for Python Code
    Geändert von Joghurt (10-10-2006 um 19:19 Uhr)

  9. #9
    Registrierter Benutzer
    Registriert seit
    10.10.2005
    Beiträge
    39
    Zitat Zitat von Joghurt Beitrag anzeigen
    Das macht aber auch Sinn. In C++ und Java wird "self" ja immer implizit übergeben (dort heisst es this). Da bei Python Variablen nicht deklariert werden, muss die Referenz auf self immer angegeben werden, damit man zwischen (Methoden-)lokalen und Instanzvariablen unterscheiden kann. Desweiteren ist es notwendig, weil du Methoden dynamisch hinzufügen (oder löschen) kannst...
    es ist in einer rein objektorientierten sprache (als was einem python ja immer verkauft wird), nicht sinn und zweck, prozedural zu programmieren von daher sollte das implizierte uebergeben von self standard sein. und das nichtdeklarieren von variablen in den meisten interpretierten sprachen halte ich persoenlich fuer einen bug und nicht fuer ein feature. und das dynamische hinzufuegen von methoden magst DU fuer 'ne tolle idee halten, der mensch der deinen code irgendwann verstehen und modifizieren muss, ist da sicher anderer meinung...

    Zitat Zitat von Joghurt Beitrag anzeigen
    Das stimmt. Das ist per design. Python geht davon aus, das der Programmierer weiss, was er tut und dass er sich an Konventionen hält. Z.B. sind Methoden, die mit einem _ beginnen, Klassenintern und nicht als Teil der API zu betrachten. Wenn man sie aber unbedingt aufrufen will, kann man es tun, sollte sich aber nicht wundern, wenn das Programm mit späteren Versionen der API nicht geht.
    ein programmierer, der weiss was er tut, ist eine illusion... modifikatoren wie private/protected/public oder static/virtual lassen wesentlich genauere annahmen zu, was ein entwickler mit einem bestimmten befehl beabsichtigt (hat). das kann einem auch helfen, seinen eigenen code irgendwann mal wieder zu verstehen. hierzu gehoert ebenfalls das deklarieren von variablen mit einem datentyp, der erkennen laesst, was damit gemacht werden soll.

    und eine methode zu deklarieren, die verschiedene arten von eingabedaten akzeptiert und dann eine pruefung auf jede moegliche kombination von typen ist sicher nicht angenehmer, als in einer typisierten sprache eine methode einfach zu ueberladen...


    Zitat Zitat von Joghurt Beitrag anzeigen
    wenn ich mir packages wie "_mysql", "PIL" oder auch einige standardmodule anschaue, kann ich das nicht glauben... "StringIO.StringIO"??? wtf...

  10. #10
    Registrierter Benutzer
    Registriert seit
    25.10.2004
    Beiträge
    819
    Zitat Zitat von OpOs Beitrag anzeigen
    es ist in einer rein objektorientierten sprache (als was einem python ja immer verkauft wird)
    Python ist eine multi-paradigm-Sprache. Imperative, objektorientierte, funktionelle und teilweise auch aspektorientierte Programmierung wird unterstützt.

    von daher sollte das implizierte uebergeben von self standard sein.
    Das Widerspricht der Python-Philosophie: "explicit is better than implicit"

    und eine methode zu deklarieren, die verschiedene arten von eingabedaten akzeptiert und dann eine pruefung auf jede moegliche kombination von typen ist sicher nicht angenehmer, als in einer typisierten sprache eine methode einfach zu ueberladen...
    Wenn man sowas macht, versucht man, C++ oder Java in Python zu programmieren und macht etwas falsch. Slange die übergebenen Objekte die benutzen Methoden implementieren, ist es Wurst, von welcher Klasse sie abgeleitet sind. In der Praxis überlädt meine eine Methode ja auch höchstens so:
    Code:
    int foo(int bar, int baz);
    int foo(float bar, float baz);
    int foo(SupidupiInt bar, SupidupiInt baz);
    und nicht so
    Code:
    int foo(int bar, int baz);
    int foo(FILE* zieldatei, const char* zu_schreibender_string)
    Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests )
    Aber du hast recht, ein "Interface"-System wie bei Java wäre ganz nett. Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.

    Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.
    Als ich mit Python anfingt, hatte ich auch Bedenken ob des "Duck-typing" Ansatzes und den fehlendem private. In der Praxis bringt das aber mehr Vorteile als die theoretischen Nachteile.

    wenn ich mir packages wie "_mysql", "PIL" oder auch einige standardmodule anschaue, kann ich das nicht glauben... "StringIO.StringIO"??? wtf...
    Ja, das Crux der Rückwärtskompabilität. Ich denke mal, dass wird in Python 3000 auch korrigiert.
    Geändert von Joghurt (13-10-2006 um 11:35 Uhr)

  11. #11
    Registrierter Benutzer
    Registriert seit
    10.10.2005
    Beiträge
    39
    Zitat Zitat von Joghurt Beitrag anzeigen
    In der Praxis überlädt meine eine Methode ja auch höchstens so:
    Code:
    int foo(int bar, int baz);
    int foo(float bar, float baz);
    int foo(SupidupiInt bar, SupidupiInt baz);
    und nicht so
    Code:
    int foo(int bar, int baz);
    int foo(FILE* zieldatei, const char* zu_schreibender_string)
    aber diese ueberladung:
    Code:
    collection.add(object)
    collection.add(array of object)
    macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in python

    Zitat Zitat von Joghurt Beitrag anzeigen
    Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests )
    mir persoenlich ist es lieber, dass der compiler meckert, als dass ich ein fehlerhaftes und dadurch potenziell verheerendes programm ausfuehre, aber das mag meine persoenliche meinung sein.

    Zitat Zitat von Joghurt Beitrag anzeigen
    Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.
    dazu muss der entwickler die funktion aber auch entsprechend ausfuehrlich dokumentieren, waehrend es in java bereits aus der deklaration ersichtlich ist und man bei der doku weniger aufwand hat.

    Zitat Zitat von Joghurt Beitrag anzeigen
    Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.
    sei doch froh, dass dich der compiler darauf hingewiesen hat BEVOR du dir eventuell das system kaputt gemacht hast. mag ja sein, dass es nichts gegaehrliches war, aber wird es beim naechsten mal auch so sein...

    wie gesagt, ich nutze python auch recht gerne, man muss sich aber im klaren ueber die fallstricke sein!

    ich weiss, in c kann man mit dem zeigergefummle geausoviel bockmist machen, aber ich hab ja nich gesagt, dass c das gelbe vom ei iss.

  12. #12
    Registrierter Benutzer
    Registriert seit
    25.10.2004
    Beiträge
    819
    Zitat Zitat von OpOs Beitrag anzeigen
    aber diese ueberladung:
    Code:
    collection.add(object)
    collection.add(array of object)
    macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in python
    In Python würdest du nur die "array of object" Methode definieren. Wenn jemand ein einfaches Objekt hat, macht er einfach beim Aufruf ein Tupel draus:
    Code:
    foo(liste_von_objekten)
    foo((einzelnes_objekt,)) # oder foo([einzelnes_objekt])

  13. #13
    Registrierter Benutzer Avatar von Romanday
    Registriert seit
    03.02.2004
    Beiträge
    829
    Was mich mal interessieren würde:

    Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
    Welches Problem läßt sich nicht viel schneller mit einer anderen
    Programmiersprache lösen?

    (Außer die 3D - Ünterstützung habe ich bis jetzt nichts gefunden.)
    Abriss, bzw. die Sprengung des World Trade Centers
    WDR Dokumentation
    Doku + DT Untertitel
    Weitere Infos - Terrorstorm

  14. #14
    Registrierter Benutzer
    Registriert seit
    05.09.2002
    Ort
    Neuhausen
    Beiträge
    320
    Zitat Zitat von Romanday Beitrag anzeigen
    Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
    Welches Problem läßt sich nicht viel schneller mit einer anderen
    Programmiersprache lösen?
    Der Einsatz von Python ist nur dort zwingen notwendig wo Python vorausgesetzt wird oder Python bereits im Einsatz ist. Und sinnvoll ist es oft, hängt aber mit der jeweiligen Situation ab. Zudem lässt sich jedes Problem mit einer anderen Programmiersprache schneller lösen, vorausgesetzt man nimmt die richtige, andere Programmiersprache.

    Diese Antwort dürfte etwas so gummig sein, wie die Frage.

    Gruss, Andy

  15. #15
    Registrierter Benutzer Avatar von Romanday
    Registriert seit
    03.02.2004
    Beiträge
    829
    Zitat Zitat von RapidMax Beitrag anzeigen
    Diese Antwort dürfte etwas so gummig sein, wie die Frage.

    Gruss, Andy
    Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
    Hauptvorteil in Python das nur wenige User den Code verstehen.

    Stichwort: Verbreitungsgrad

    Aus der anderen Seite gibt es leider nicht so eine große Auswahl
    an fertigen Apps.
    Bis jetzt sehe ich einfach noch keinen Sinn darin in Python tiefer
    einzusteigen. Der Reiz fehlt. Ich sehe noch nicht die Vorteile.
    Was soll ich damit zusammenbasteln, was es nicht schon in anderen
    Sprachen gibt?
    Abriss, bzw. die Sprengung des World Trade Centers
    WDR Dokumentation
    Doku + DT Untertitel
    Weitere Infos - Terrorstorm

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •