Python / Perl - was ist besser geeignet?

[BlackJack]

@DanielH: Du machst Dir *wirklich* zu viele Gedanken um Geschwindigkeit. So wie Du drauf bist, solltest Du am besten Assembler benutzen.

Dein Argument warum reguläre Ausdrücke in Python langsamer sein dürften habe ich übrigens nicht verstanden!?

Für eingeschränktes oder leicht modifiziertes Python gibt's mit Pyrex/Cython, RPython von PyPy, und ShedSkin auch Möglichkeiten C bzw. C++ Quelltext zu erzeugen. Und es gibt den JIT-Compiler Psyco. Aber hast Du denn überhaupt vor "Numbercrunching" zu betreiben? Denn ansonsten wird das typische "Internet"- oder "Loganalyse"-Skript die meiste Zeit mit warten auf Daten oder in der Implementierung von regulären Ausdrücken stecken, die sowieso schon in C geschrieben ist.

[Mad-Marty]

@DanielH:
Perl ist optimal für dein vorhaben, garantiert!

Na das will ich doch mal aber ganz stark anzweifeln.

Perl's threading ist sowas von vermurkst, das man das garnicht so nennen kann. Gerade ältere Perl versionen sind da besonders grottig.

Dann stellt sich noch die Frage ob sein ProxyCheck von anderen OSen ausser linux aus laufen soll.

Select muss auch nicht unbedingt die beste Lösung sein, gerade wieder im hinblick auf Unterschiedliche OS.

Ich würds mit Python machen und erstmal Select versuchen.


Zur Performance: In allen Tests die ich gemacht habe schlägt Python Perl teils sogar gravierend.

[skypa]

@DanielH:
Perl ist optimal für dein vorhaben, garantiert!

Na das will ich doch mal aber ganz stark anzweifeln.

Perl's threading ist sowas von vermurkst, das man das garnicht so nennen kann. Gerade ältere Perl versionen sind da besonders grottig.

Wer benutzt denn freiwillig eine ältere Version? Was für ein Argument!

[BlackJack]

Wenn man an das gebunden ist, was der Webhoster bietet, benutzt man vielleicht *unfreiwillig* eine ältere Version.

[skypa]

Ja das stimmt wohl, hab von solchen Vorfällen auch schon gehört. Hab auch zu gegebener Maßen kaum was mit Hostern zu tun. Das kommt später mal

[keppla]

Mir fällt es immer etwas schwer, das Argument der Webhoster nachzuvollziehen.

Wenn ich es professionell mache, ist es eine Frage des Stundenlohns, wenn ich es als Hobby mache, eines meiner Nerven.

Wenn man es billig will, kriegt man bei Hosteurope z.B.ab 3€/Monat einen Webspace mit Python. Da kann man imho auch als Hobbyist recht gut finanztechnisch mithalten.

Wenn man mal überlegt, was eine Stunde der eigenen Arbeit kostet (hoffentlich mehr als 10€) kann man nur sagen, dass man sich nur eine Stunde/Monat mit einer alten Version, falschen Sprache oder etwas anderem, bei webhostern unkontrollierbaren rumschlagen muss, dass sich ein vhost für 10€/Monat lohnt (wo man die totale kontrolle hat).

Kurz, ausser dem irrationalen Wunsch eines Kunden, mehr Geld auszugeben, oder eigenem Masochismus fällt mir nichts ein, was den Webhoster als Argument enthält.

[Leonidas]

Mir geht es auch nicht darum, ob es funktioniert, sondern womit es am besten
funktioniert (siehe Thread-Überschrift ). Und ich hab den Eindruck, dass Perl besser
geeignet ist.

Wenn man die Diskussion so verfolgt, liest man dass du überlegst, wo Threads am besten funktionieren. Nicht wie man das Problem am besten löst Vielleicht solltest du deine Idee, Threads zu verwenden loslassen
Über die Thread-Performance von Python vs Perl kann man aber wenig aussagen, da müsste man das gleiche Programm in beiden Sprachen schreiben und gucken.

vermutlich werde ich viel mit RegEx arbeiten
müssen, und Python verwendet ja den engine von Perl, was langsamer sein dürfte / ...)

Also das Argument verstehe ich nun überhaupt nicht. Erstens nutzt Python nicht die Engine von Perl, auch nicht PCRE. Zweitens sehe ich nicht was daran per-se so dramatisch langsamer sein soll. Reguläre Ausdrücke so wie sie in Perl, Python, Ruby implementiert sind nun mal recht langsam, siehe Regular Expression Matching Can Be Simple And Fast.

Aber Apropos: ein anderer Punkt gegen Python war, dass mein Provider Python offiziell
nicht unterstützt (momentan hab noch „normalen“ Webspace). Inoffiziell könne ich zwar
Python-Scripte über CGI laufen lassen, aber sie würden keinen Support für Python
anbieten (welchen ich momentan ganz sicher brauchen würde).

Den "Support" von Providern kann man in der Regel vergessen, von denen kannst du (in aller Regel) nichts erwarten. Da mich das auch gestört habe, und ich einen zusätzlichen Shared Hosting-Account (mit Python und allem drum und dran) gebraucht habe, bin ich Pyhosting beigetreten. Kann ich eigentlich nur empfehlen.

Und dadurch, dass ich nur Webspace hab, kann ich 'Parallel python' sowieso vergessen,
bis ich mir nen eignen Server hole oder den Webhoster wechsle (weil soweit ich mich
erinnere, muss 'Parallel python' installiert werden, was ich ja vermutlich ohne root
Rechte vergessen kann).

In der Regel kannst du Python-Pakete ohne root-Rechte installieren. Das mache ich auf meinem Shared-Hosting-Account auch so. Ein SSH-Account ist da jedoch von Vorteil.

[DanielH]

hier noch kleiner Hinweis falls du darauf noch nicht gestoßen bist: www.perlboard.de

Kannte ich schon, aber trotzdem danke.

@DanielH: Du machst Dir *wirklich* zu viele Gedanken um Geschwindigkeit. So wie Du drauf bist, solltest Du am besten Assembler benutzen.

Langsam fang ich auch an dran zu glauben
Naja, egal, außer etwas Zeit, die ich eventuell verlieren könnte, wenn ich Perl UND Python lerne, sehe ich keine Nachteile (dafür aber viele Vorteile).

Und so lange wird es wohl nicht dauern die Basics von Perl zu lernen (Ich hab jetzt angefangen ein Tutorial zu lesen; wenn ich mit dem Tempo weiter lerne, bin ich in 1 bis 3 Tagen fertig).


BlackJack hat folgendes geschrieben:

Dein Argument warum reguläre Ausdrücke in Python langsamer sein dürften habe ich übrigens nicht verstanden!?

Leonidas hat folgendes geschrieben:

Also das Argument verstehe ich nun überhaupt nicht. Erstens nutzt Python nicht die Engine von Perl, auch nicht PCRE. Zweitens sehe ich nicht was daran per-se so dramatisch langsamer sein soll. Reguläre Ausdrücke so wie sie in Perl, Python, Ruby implementiert sind nun mal recht langsam, siehe Regular Expression Matching Can Be Simple And Fast.

Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann dachte ich Python würde diesen verwenden (Und dadurch, dass Python nicht seinen eignen engine benutze, wäre Python langsamer).


BlackJack hat folgendes geschrieben:

Für eingeschränktes oder leicht modifiziertes Python gibt's mit Pyrex/Cython, RPython von PyPy, und ShedSkin auch Möglichkeiten C bzw. C++ Quelltext zu erzeugen.

Danke für den Hinweis! Das muss ich mir dann auf jeden Fall ganz genau ansehen.

Aber hast Du denn überhaupt vor "Numbercrunching" zu betreiben?

Ich denke „erstmal“ nein.

Denn ansonsten wird das typische "Internet"- oder "Loganalyse"-Skript die meiste Zeit mit warten auf Daten oder in der Implementierung von regulären Ausdrücken stecken, die sowieso schon in C geschrieben ist.

Ach so, ich dachte dadurch, dass ich mehrere Anfragen auf einmal mache, „umgehe“ ich die Wartezeit, und kann die Ressourcen voll ausnutzen, wodurch es einen zusätzlichen Vorteil geben würde, wenn ich kompilierten Code verwende.


Mad-Marty hat folgendes geschrieben:

Dann stellt sich noch die Frage ob sein ProxyCheck von anderen OSen ausser linux aus laufen soll.

Nein, das Script soll nur unter Linux laufen (Windows soll ja für multi-threading nicht gerade ideal sein, hab ich gelesen..).


keppla hat folgendes geschrieben:

Mir fällt es immer etwas schwer, das Argument der Webhoster nachzuvollziehen.

Wenn ich es professionell mache, ist es eine Frage des Stundenlohns, wenn ich es als Hobby mache, eines meiner Nerven.

Wenn man es billig will, kriegt man bei Hosteurope z.B.ab 3€/Monat einen Webspace mit Python. Da kann man imho auch als Hobbyist recht gut finanztechnisch mithalten.

Wenn man mal überlegt, was eine Stunde der eigenen Arbeit kostet (hoffentlich mehr als 10€) kann man nur sagen, dass man sich nur eine Stunde/Monat mit einer alten Version, falschen Sprache oder etwas anderem, bei webhostern unkontrollierbaren rumschlagen muss, dass sich ein vhost für 10€/Monat lohnt (wo man die totale kontrolle hat).

Kurz, ausser dem irrationalen Wunsch eines Kunden, mehr Geld auszugeben, oder eigenem Masochismus fällt mir nichts ein, was den Webhoster als Argument enthält.

Im Prinzip hast Du vollkommen Recht. Ca. Anfang des nächsten Jahres werde ich mir wohl auch einen VPS holen, denke ich. Bis dahin will ich mir aber nicht extra noch ein weiteres Hostingpaket zulegen (ich hab sowieso schon viel zu viele Domains und Hostingpakete, die quasi ungenutzt sind )


Leonidas hat folgendes geschrieben:

Wenn man die Diskussion so verfolgt, liest man dass du überlegst, wo Threads am besten funktionieren. Nicht wie man das Problem am besten löst Vielleicht solltest du deine Idee, Threads zu verwenden loslassen

Also eigentlich ist mir egal *wie*, Hauptsache schnell
Ich weiß nicht mehr wo, aber irgendwo hab ich gelesen, dass eine Kombination aus Prozessen und Threads effizient sein soll (also dass es mehrere Prozesse gibt, welche jeweils mehrere Threads haben).


Mad-Marty hat folgendes geschrieben:

Zur Performance: In allen Tests die ich gemacht habe schlägt Python Perl teils sogar gravierend.

Leonidas hat folgendes geschrieben:

Über die Thread-Performance von Python vs Perl kann man aber wenig aussagen, da müsste man das gleiche Programm in beiden Sprachen schreiben und gucken.

Ich glaub, wenn ich die Basics von Perl und Python einigermaßen schnell lerne, schreib ich das Script nochmal in Python. Meine Neugierde ist jetzt viel zu groß, um das nicht zu machen.

In der Regel kannst du Python-Pakete ohne root-Rechte installieren. Das mache ich auf meinem Shared-Hosting-Account auch so. Ein SSH-Account ist da jedoch von Vorteil.

SSH hab ich anscheinend nicht, aber ich denke, ich werde die Python-Scripte ertmal auf meinem PC testen/laufen lassen (ich hab ja dann sowieso schon die Perl Variante, die auf dem Server laufen kann).

Den "Support" von Providern kann man in der Regel vergessen, von denen kannst du (in aller Regel) nichts erwarten.

Da geb ich Dir zu 100% Recht; Bei den meisten Hostern ist der Support extrem schlecht.
Mein Hoster ist da allerdings eine Ausnahme ( http://all-inkl.com/ ).

Zum Beispiel hab schon oft mitten in der Nacht (ca. 2 bis 4 Uhr) ne Anfrage gesendet, und hatte i. d. R. immer nach 30 bis 60 Minuten eine Antwort. Und die Antworten vom Support sind immer extrem hilfreich.
Zweimal haben die mir sogar gesagt, warum mein Script nicht läuft (nachdem ich es dem Support gesendet hatte, weil ich den Verdacht hatte, dass es wegen der Server-Konfiguration nicht läuft). Als ein Script nicht funktioniert hat, weil ich es mit php 5 entwickelt hatte, auf dem Server aber nur php 4 war haben die meine Domains ect. *über Nacht* auf einen Server mit php 5 verschoben.

Ich kann nur sagen, der Webhoster ist der Oberhammer


PS: eine Sache, die ich bei Perl extrem beschissen finde, ist dass fast jeder Variablentyp anders gekennzeichnet wird (int./float/string = $, array = @, assoziatives array bzw. hash = %). Bei php ist alles mit $ gekennzeichnet und bei Python gibt es überhaupt keine Kennzeichnung (wenn ich das richtig in Erinnerung habe). Aber das ist wohl nur eine Gewöhnungssache...

[Rebecca]

Multithreading und Multiprocessing ist sinnvoll fuer CPU-lastige nebenlaeufige Programme, fuer IO-lastige Programme aber eventuell nicht optimal. Es gibt noch eine andere Moeglichkeit! Ich zitiere mal die Doku vom asyncore-Modul:

There are only two ways to have a program on a single processor do ``more than one thing at a time.'' Multi-threaded programming is the simplest and most popular way to do it, but there is another very different technique, that lets you have nearly all the advantages of multi-threading, without actually using multiple threads. It's really only practical if your program is largely I/O bound. If your program is processor bound, then pre-emptive scheduled threads are probably what you really need. Network servers are rarely processor bound, however.

If your operating system supports the select() system call in its I/O library (and nearly all do), then you can use it to juggle multiple communication channels at once; doing other work while your I/O is taking place in the ``background.'' Although this strategy can seem strange and complex, especially at first, it is in many ways easier to understand and control than multi-threaded programming. The asyncore module solves many of the difficult problems for you, making the task of building sophisticated high-performance network servers and clients a snap. For ``conversational'' applications and protocols the companion asynchat module is invaluable.

[BlackJack]

Wo Perl für mich an Grenzen gestossen ist, waren verschachtelte Datenstrukturen und OOP. Da hat für mich Python klar die Nase vorn.

[Leonidas]

Naja, egal, außer etwas Zeit, die ich eventuell verlieren könnte, wenn ich Perl UND Python lerne, sehe ich keine Nachteile (dafür aber viele Vorteile).

Und so lange wird es wohl nicht dauern die Basics von Perl zu lernen (Ich hab jetzt angefangen ein Tutorial zu lesen; wenn ich mit dem Tempo weiter lerne, bin ich in 1 bis 3 Tagen fertig).

Ja, die Basics bekommst du schnell hin, das stimmt. Aber die richtigen Features einer Programmiersprache lernst du erst wenn du dich intensiv damit beschäftigst. Damit will ich dich natürlich nicht von dem Entschluss beide Sprachen zu lernen abbringen, will dir nur sagen, dass nachdem man die Basics hat, die richtig tollen Sachen erst noch kommen. Das sehe ich an mir selbst, wenn ich meine alten Programme anschaue und mir an den Kopf fassen muss, was ich damals zusammengeschrieben habe.

Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann dachte ich Python würde diesen verwenden (Und dadurch, dass Python nicht seinen eignen engine benutze, wäre Python langsamer).

Das Verwenden von "Fremdengines" muss nicht per-se langsam sein. Die Python-Regex-Engine besteht aus einer Mischung von Python-Dateien und einem C-Shared-Object (also etwa einer DLL), `sre`. Wenn Python PCRE verwenden würde, dann wäre es ganz ähnlich. Die Performance der Regular-Expressions ist eher weniger durch die Art der Anbindung definiert, sondern durch die Geschwindigkeit der Regex-Engine. In Python kannst du (theoretisch) neben `sre` auch `Oniguruma` oder `TRE` verwenden. Praktisch geht das nicht, weil beide Bindings noch nicht funktionieren.

[Y0Gi]

Da geb ich Dir zu 100% Recht; Bei den meisten Hostern ist der Support extrem schlecht.
Mein Hoster ist da allerdings eine Ausnahme ( http://all-inkl.com/ ).

Ich kann nur sagen, der Webhoster ist der Oberhammer

Letzteres kann ich bestätigen: Zu meiner Zeit bei all-inkl tauche mal eine weitere Datenbank im Frontend (PMA) auf. Nach etwas Überfliegen stellte sich heraus, dass dies eine produktiv genutzte Datenbank eines anderen Kunden war. Die schlauerweise auch noch Passwörter enthielt - im Klartext! *Das* war der Oberhammer

Den einen oder anderen Tag habe ich abgewartet in der Annahme, das würde sicher jemand bemerken und korrigieren - dem war jedoch nicht so. Entsprechend habe ich den Support auf die Problematik aufmerksam gemacht und es wurde immerhin entsprechend reagiert.

Tjoa, und einige Zeit später wechselten wir dann zu einem anderen Hoster, der hoffentlich mehr von Sicherheit verstand. Bei All-inkl kann man schon mal leicht am falschen Ende gespart haben.

[DanielH]

Multithreading und Multiprocessing ist sinnvoll fuer CPU-lastige nebenlaeufige Programme, fuer IO-lastige Programme aber eventuell nicht optimal. Es gibt noch eine andere Moeglichkeit! Ich zitiere mal die Doku vom asyncore-Modul:

Danke Rebecca, jetzt versteh ich's

(Du hattest ja schon mal asyncore erwähnt; allerdings bin ich nicht auf die Idee gekommen mal danach zu googln, bzw. ich hab gedacht ich wüste ungefähr, was es ist)

Ja, die Basics bekommst du schnell hin, das stimmt. Aber die richtigen Features einer Programmiersprache lernst du erst wenn du dich intensiv damit beschäftigst. Damit will ich dich natürlich nicht von dem Entschluss beide Sprachen zu lernen abbringen, will dir nur sagen, dass nachdem man die Basics hat, die richtig tollen Sachen erst noch kommen. Das sehe ich an mir selbst, wenn ich meine alten Programme anschaue und mir an den Kopf fassen muss, was ich damals zusammengeschrieben habe.

Da hast Du sicherlich Recht. Vermutlich werde ich mich auch früher oder später mit einer Sprache intensiver beschäftigen, als mit der/den Anderen (ich denke das kommt ganz automatisch ).

Aber ehrlich gesagt bin ich schon glücklich, wenn ich fremde Scripte einigermaßen gut verstehe (mit ner kurzer Recherche nach unbekannten Funktionen ect.). Denn, erstens kann man alleine durch das Abändern von fremden Scripte eine Menge realisieren, und zweitens lernt man dadurch auch ziemlich schnell (finde ich).

Letzteres kann ich bestätigen: Zu meiner Zeit bei all-inkl tauche mal eine weitere Datenbank im Frontend (PMA) auf. Nach etwas Überfliegen stellte sich heraus, dass dies eine produktiv genutzte Datenbank eines anderen Kunden war. Die schlauerweise auch noch Passwörter enthielt - im Klartext! *Das* war der Oberhammer

Den einen oder anderen Tag habe ich abgewartet in der Annahme, das würde sicher jemand bemerken und korrigieren - dem war jedoch nicht so. Entsprechend habe ich den Support auf die Problematik aufmerksam gemacht und es wurde immerhin entsprechend reagiert.

Tjoa, und einige Zeit später wechselten wir dann zu einem anderen Hoster, der hoffentlich mehr von Sicherheit verstand. Bei All-inkl kann man schon mal leicht am falschen Ende gespart haben.

Ui, ok, das ich schon heftig. Wann war das denn? (Ist hoffentlich schon länger her )

Das ist aber ehrlich gesagt erst das erste Mal, dass ich über die was schlechtes gehört habe.

Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann [...]

Das scheint aber zu stimmen? Auf jeden Fall konnte ich quasi keinen Unterschied zwischen Perl engine und PCRE feststellen.

[Y0Gi]

Ui, ok, das ich schon heftig. Wann war das denn? (Ist hoffentlich schon länger her )

Ja, das ist schon einige Jahre her. Das muss dennoch nichts heißen.

Das ist aber ehrlich gesagt erst das erste Mal, dass ich über die was schlechtes gehört habe.

Das mag daran liegen, dass unzufriedene Kunden oft ihr Feedback für sich behalten. Oder daran, dass viele "bei mir lief alles glatt" mit "alles ist perfekt" gleichsetzen und das dann so propagieren.

[Leonidas]

Ach so, da hab ich dann wohl irgendwas falsch verstanden. Erstmal dachte ich PCRE sei der leicht modifizierte Perl engine, und dann [...]

Das scheint aber zu stimmen? Auf jeden Fall konnte ich quasi keinen Unterschied zwischen Perl engine und PCRE feststellen.

Nein, stimmt nicht:

Perl Compatible Regular Expressions (kurz PCRE, deutsch Perl-Kompatible Reguläre Ausdrücke) ist eine Programmbibliothek zur Auswertung von Regulären Ausdrücken. Der Name bezieht sich darauf, dass die Syntax der Ausdrücke der Programmiersprache Perl entliehen wurde. Sie entsprechen etwa dem Stand von Perl 5.0, beinhaltet aber auch zusätzliche, im POSIX-Standard definierte Ausdrücke, die auch teilweise erst von Perl 5.10 aufgenommen werden. Trotzdem gibt es viele Unterschiede zwischen den heutigen, von Perl verwendeten Regex und PCRE da perl nach 5.0 stark erweitert wurde.

Die Unterschiede beziehen sich wohl auf weniger bekannte Features der Perl-Regex. Perl Regular Expressions sind unglaublich umfangreich, aber der Versuch diese Features zu nutzen kann recht einfach zu absolut unlesbaren Programmen führen.

[birkenfeld]

Perl Regular Expressions sind unglaublich umfangreich, aber der Versuch diese Features zu nutzen kann recht einfach zu absolut unlesbaren Programmen führen.

Vor allem diejenigen, die wiederum Perl-Code in REs integrieren und dadurch auch durch PCRE nicht implementierbar sind.

[BlackVivi]

Perl Regular Expressions sind unglaublich umfangreich, aber der Versuch diese Features zu nutzen kann recht einfach zu absolut unlesbaren Programmen führen.

Das war doch einer der Gründe, warum überlegt wurde REs aus Python zu entfernen, oder?... Ich meine, REs (insbesondere umfangreiche) sollten immer gut dokumentiert sein, dabei ist es egal in welcher Sprache. Oder seh ich das falsch?... Von REs weiß ich sehr wenig o_o

[Leonidas]

Vor allem diejenigen, die wiederum Perl-Code in REs integrieren und dadurch auch durch PCRE nicht implementierbar sind.

Da fällt mir eines meiner [wiki=IRC_Channel/Zitate#DieZukunftVonRuby]Lieblingszitate[/wiki] ein

[birkenfeld]

Das war doch einer der Gründe, warum überlegt wurde REs aus Python zu entfernen, oder?

Ich kann mir nicht vorstellen, dass das jemals ernsthaft überlegt wurde.

[BlackVivi]

Das war doch einer der Gründe, warum überlegt wurde REs aus Python zu entfernen, oder?

Ich kann mir nicht vorstellen, dass das jemals ernsthaft überlegt wurde.

Ich kann mich natürlich auch irren, aber meiner Meinung nach gab es mal eine Diskussion in'r Mailinglist, wo darüber nachgedacht wurde sie zu entfernen... Wegen der Lesbarkeit. Aber das ist schon sehr lang' her. Aber REs sind inzwischen nicht mehr wegzudenken...