Python vs. PHP
Christian Helmbold
ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
PHP in der Regel ganz gut durch Python ersetzen können müsste.
Vielleicht hat ja der ein oder andere von euch Erfahrungen mit PHP
gesammelt und kann meine Auflistung ergänzen oder etwas zu dem
Python-Teil beisteuern.
Gruß
Christian
--
E-Mails werden nur mit Glück gelesen.
Schönschrift für Mails: "Bitstream Vera Sans Mono"
http://www.gnome.org/fonts/
Stefan Scholl
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
Wozu? Gibt es eine Sprache die schlechter ist als PHP?
PHP hatte anfangs ja den angeblichen Vorteil mit HTML-Code
gemischt zu sein. Heutzutage sagen sogar die PHP-"Profis" man
solle ein Template benutzen.
Also hebt sich PHP in dieser Hinsicht von keiner anderen Sprache
ab. Es gibt praktisch keine lebende Programmiersprache, für die
es keine Webanbindung gibt.
"Sollen wir für das Projekt PHP nehmen, oder ..." - "ODER!!"
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Gerold Penz
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
Hallo Christian!
Ich weiß nicht ob es dir bewusst ist, aber mit solchen "Kampfreden"
schadest du dem Ansehen von Python. Haben wir es wirklich nötig, andere
schlecht zu machen? -- Ich sage NEIN!
Leben und leben lassen.
mfg
Gerold
:-)
--
________________________________________________________________________
Gerold Penz - bcom - Programmierung
gerol...@tirol.utanet.at | http://gerold.bcom.at | http://sw3.at
Ehrliche, herzliche Begeisterung ist einer der
wirksamsten Erfolgsfaktoren. Dale Carnegie
Martin Kaffanke
> Hallo,
>
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>
> http://helmbold.de/it/php/
>
> Vielleicht hat ja der ein oder andere von euch Erfahrungen mit PHP
> gesammelt und kann meine Auflistung ergänzen oder etwas zu dem
> Python-Teil beisteuern.
Naja, vor allem bei dem 'Vorteile von Python' Absatz fehlen die Belege,
im Grunde sollte jede Aussage irgendwie veranschaulicht werden, vielleicht
mit Links auf eigenen Seiten, wo dies auch gezeigt wird. Z.B. warum du
meinst, dass man php nicht für Applikationen außerhalb des Webs
einsetzen könnte (siehe php als Scriptsprache, oder php-gtk). Oder auch
das python weniger Fehler und Sicherheitslücken habe, das kann man nicht
so einfach stehen lassen, das braucht Belege. Oder auch warum man bei
web-applikationen - und die PHP Nutzer betonen sehr häufig, php sei allen
anderen Sprachen in der Web-Programmierung überlegen, gerade weil es für
das Web konzpiert wurde - unbedingt threads braucht. Threads sind nur im
geringen Maße tatsächlich nützlich, und werden erst dann wirklich
relevant, wenn man die Aufgabe auf mehrere Prozessoren aufteilen kann, und
so weit ich weiß, unterstützt Python noch keine Mehreren Prozessoren,
das heißt, jedes Python-Script läuft auf genau einem Prozessor, wenn
mehrere verfügbar sind.
Ich bevorzuge auch Python gegenüber PHP, aber wohl aus dem selben Grund,
warum ich lieber Schokolade esse als Chips - subjektive Präferenz.
lg,
Martin
Christian Helmbold
> Christian Helmbold schrieb:
>> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
>> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
>> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>
> Hallo Christian!
>
> Ich weiß nicht ob es dir bewusst ist, aber mit solchen "Kampfreden"
> schadest du dem Ansehen von Python. Haben wir es wirklich nötig, andere
> schlecht zu machen? -- Ich sage NEIN!
>
> Leben und leben lassen.
>
> mfg
> Gerold
> :-)
>
Python habe ich in erster Linie ins Spiel gebracht, um den
PHP-Programmierer, der sich bewusst wird, wie schlecht PHP eigentlich
ist, einen Ausweg sieht. Es war nicht mein Ziel, Python durch
Herabsetzung anderer Sprachen besser dastehen zu lassen. Das hat Python
in der Tat nicht nötig. Mal gucken, vielleicht kann ich etwas anders
formulieren.
Stefan Scholl
> Ich weiß nicht ob es dir bewusst ist, aber mit solchen "Kampfreden"
> schadest du dem Ansehen von Python. Haben wir es wirklich nötig, andere
> schlecht zu machen? -- Ich sage NEIN!
>
> Leben und leben lassen.
So ähnlich habe ich einmal bei einer Common-Lisp-Diskussion
geantwortet. Was man mir aber erwidert hat war nachvollziehbar:
Wenn allen Ortes die schlechteren Lösungen benutzt werden, dann
betrifft mich das auch. Ich bin ja mehr und mehr von Software
abhängig, die andere Menschen geschrieben haben.
Und die Tendenz geht schon lange in Richtung Web.
Etwas _gegen_ PHP zu sagen ist also wichtig. Zu viele Anfänger
fallen auf PHP herein. Und als Konsequenz müssen wir alle
darunter leiden.
Nur darf man dabei nicht zu sehr auf Python pochen. Python sollte
sowieso (wie PHP notfalls auch) nur _ein_ Teil im Werkzeugkasten
eines Programmierers sein.
Thomas Guettler
> Hallo,
>
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>
> http://helmbold.de/it/php/
Ich habe die Punkte warum ich von Perl nach Python
umgestiegen bin aufgeschrieben:
http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl2python
Viele Perlfreunde fühlten sich dadurch angegriffen, besonders
da ich zuerst "Warum nicht Perl" als Überschrift benutzt habe.
Die neue
Überschrift (Warum ich von Perl zu Python umgestiegen bin) ist weniger
"feindlich", auch wenn der Inhalt fast gleich bleibt.
Thomas
--
Thomas Güttler, http://www.thomas-guettler.de/ http://www.tbz-pariv.de/
E-Mail: guettli (*) thomas-guettler + de
Spam Catcher: niemand....@thomas-guettler.de
Matthias Esken
> http://helmbold.de/it/php/
>
> Vielleicht hat ja der ein oder andere von euch Erfahrungen mit PHP
> gesammelt und kann meine Auflistung ergänzen oder etwas zu dem
> Python-Teil beisteuern.
Als Entwickler, der mit PHP sehr vertraut ist und sich gerade Python
aneignet, kann ich den Punkt mit der schlechteren Dokumentation bei PHP so
nicht nachvollziehen. Für mich hat PHP eindeutig die bessere Dokumentation
mit schönen handlichen Beispielen. Ich habe auch einige Zeit hilflos in der
Luft gerudert, bis ich Python ordentlich in den Webserver eingebunden
bekam. Anschließend musste ich mir dann von erfahrenen Kollegen sagen
lassen, dass man da ohnehin ein passendes Framework benutzen sollte. :-(
Python ist natürlich als Sprache grundsätzlich um Längen schöner und
handlicher als PHP. Früher habe ich gedacht, dass PHP einige Inkonsistenzen
und Merkwürdigkeiten hat, bis ich dann bemerkte, dass Inkonsistenzen und
Merkwürdigkeiten das Konzept von PHP sind.
Gruß,
Matthias
Christian Helmbold
> Als Entwickler, der mit PHP sehr vertraut ist und sich gerade Python
> aneignet, kann ich den Punkt mit der schlechteren Dokumentation bei PHP so
> nicht nachvollziehen. Für mich hat PHP eindeutig die bessere Dokumentation
> mit schönen handlichen Beispielen.
Großer Vorteil der Python-Doku ist, dass sie vollständig ist und
insgesamt nicht so chaotisch aussieht. Das bedeutet aber nicht, dass es
da kein Verbesserungspotenzial gäbe. Ein Freund schwärmt von der C#-
bzw. .Net-Dokumentation; die könnte vielleicht als Vorbild dienen.
> Python ist natürlich als Sprache grundsätzlich um Längen schöner und
> handlicher als PHP. Früher habe ich gedacht, dass PHP einige Inkonsistenzen
> und Merkwürdigkeiten hat, bis ich dann bemerkte, dass Inkonsistenzen und
> Merkwürdigkeiten das Konzept von PHP sind.
Schön gesagt :-)
Christian Helmbold
Thomas Guettler schrieb:
> Ich habe die Punkte warum ich von Perl nach Python
> umgestiegen bin aufgeschrieben:
>
> http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl2python
Eine schöne Dokumentation der Hässlichkeit von Perl! Möglicherweise kann
ich die demnächst mal als Argument gebrauchen.
> Viele Perlfreunde fühlten sich dadurch angegriffen, besonders
> da ich zuerst "Warum nicht Perl" als Überschrift benutzt habe.
Nach meiner Theorie verteidigen die Leute ihr System immer mit Zähnen
und Klauen, weil sie ja schlechter dastehen würden, wenn keiner mehr
ihre Künste in Anspruch nehmen würde, weil alle etwas Besseres benutzen.
Ich habe meine Überschrift auch mal etwas entschärft.
Georg Brandl
> Christian Helmbold wrote:
>
>> Hallo,
>>
>> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
>> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
>> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>>
>> http://helmbold.de/it/php/
>
> Ich habe die Punkte warum ich von Perl nach Python
> umgestiegen bin aufgeschrieben:
>
> http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl2python
>
> Viele Perlfreunde fühlten sich dadurch angegriffen, besonders
> da ich zuerst "Warum nicht Perl" als Überschrift benutzt habe.
Da könnte man vielleicht noch die umständliche Objektorientierung anfügen,
Stichwort "bless" und "package".
Georg
Martin Kaffanke
> Matthias Esken schrieb:
>
>> Als Entwickler, der mit PHP sehr vertraut ist und sich gerade Python
>> aneignet, kann ich den Punkt mit der schlechteren Dokumentation bei PHP so
>> nicht nachvollziehen. Für mich hat PHP eindeutig die bessere Dokumentation
>> mit schönen handlichen Beispielen.
>
> Großer Vorteil der Python-Doku ist, dass sie vollständig ist und
> insgesamt nicht so chaotisch aussieht. Das bedeutet aber nicht, dass es
> da kein Verbesserungspotenzial gäbe. Ein Freund schwärmt von der C#-
> bzw. .Net-Dokumentation; die könnte vielleicht als Vorbild dienen.
Ich kenne diese Dokumentationen auch nicht, aber teilweise sind in der
Python Dokumentation examples vorhanden, das ist etwas das sich leider
(noch) nicht durch die gesamte Dokumentation durch zieht, was ich aber
sehr schön finden würde, besonders wenn man ein Modul zum ersten mal
benutzt wäre sowas sehr hilfreich.
lg,
Martin
Georg Brandl
Das finde ich auch!
Allerdings lebt die Dokumentation halt hauptsächlich von den Beiträgen
Freiwilliger. Ein kleines Beispiel zu einer Moduldoku beizusteueren,
ist immer sehr willkommen!
Georg
Johannes Veser
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>
> http://helmbold.de/it/php/
Hallo Christian,
im Absatz "Aufgesetzte Objektorientierung" schreibst Du
"entsteht auch bei eigentlich objektorientierten PHP-Programmen immer
ein Mischmasch aus objektorientierter und funktionaler Programmierung".
Ich glaube, Du meinst hier "imperative Programmierung" anstatt
"funktionale Programmierung".
Ich will jetzt hier nicht Haare spalten, aber einen Anfänger könnte es
doch verwirren wenn er liest, PHP unterstütze das Konzept der
funktionalen Programmierung (wie z.B. Haskell).
Ich kenne mich mit PHP nicht wirklich aus. Wahrscheinlich unterstützt es
ähnlich Python sogar lambda-Ausdrücke. Aber zu einer funktionalen
Programmiersprache gehört deutlich mehr.
Gruß,
Johannes
Diez B. Roggisch
> "funktionale Programmierung".
Ist mir auch aufgefallen, ja.
> Ich will jetzt hier nicht Haare spalten, aber einen Anfänger könnte es
> doch verwirren wenn er liest, PHP unterstütze das Konzept der
> funktionalen Programmierung (wie z.B. Haskell).
> Ich kenne mich mit PHP nicht wirklich aus. Wahrscheinlich unterstützt es
> ähnlich Python sogar lambda-Ausdrücke. Aber zu einer funktionalen
> Programmiersprache gehört deutlich mehr.
Nein, lambda kann es nicht. Man kann allerdings Funktionen ueber ihren Namen
in einer Variable aufrufen - dadurch lassen sich zumindest theoretisch
Funktionen hoeherer Ordnung definieren.
MfG Diez
Dejan Spasic
Christian Helmbold schrieb:
> Hallo,
Hi,
> Vielleicht hat ja der ein oder andere von euch Erfahrungen mit PHP
> gesammelt und kann meine Auflistung ergänzen
http://public.yahoo.com/~radwin/talks/php-at-yahoo-zend2005.pdf
> Gruß
> Christian
Ich muss sagen, dass ich die Ganzen X vs. Y Flamewarsgeschichten immer
sehr amüsand finde :)
Gruß Dejan
Sebastian Waschik
Christian Helmbold <c.hel...@gmx.de> writes:
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
Du schreibst:
|Mal werden die Teile des Namen mit Unterschrich getrennt und mal
|werden sie direkt aneinander gehängt
Das hat doch python auch: has_key ist beispielsweise mit Unterstrich
und in unittest gibt es Methoden mit dem Namen setUp etc. (worüber
sich pylint dann auch jedesmal aufregt).
Ich glaube nicht daran, dass da etwas objektives herauskommt, wenn man
nur Argumente gegen PHP sucht und nicht vergleicht.
Viele Grüße
Sebastian Waschik
Paul Ebermann
> Christian Helmbold schrieb:
>
> > ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> > ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> > PHP in der Regel ganz gut durch Python ersetzen können müsste.
> >
> > http://helmbold.de/it/php/
>
> Hallo Christian,
>
> im Absatz "Aufgesetzte Objektorientierung" schreibst Du
> "entsteht auch bei eigentlich objektorientierten PHP-Programmen immer
> ein Mischmasch aus objektorientierter und funktionaler Programmierung".
>
> Ich glaube, Du meinst hier "imperative Programmierung" anstatt
> "funktionale Programmierung".
Nein, eigentlich meint er wohl prozedurale Programmierung
(also das, was man von Pascal kennt).
Imperativ ist AFAIK eher ein Oberbegriff dazu und
auch in Python üblich, soweit ich das bisher
beurteilen kann (bin Anfänger diesbezüglich) -
kennzeichnend dafür ist die Verwendung von
Statements (und nicht nur Expressions), und
in der Python-Spezifikation wimmelt es nur so
davon :-)
Paul
Thomas Rachel
> Du schreibst:
>
> |Mal werden die Teile des Namen mit Unterschrich getrennt und mal
> |werden sie direkt aneinander gehängt
>
> Das hat doch python auch: has_key ist beispielsweise mit Unterstrich
> und in unittest gibt es Methoden mit dem Namen setUp etc. (worüber
> sich pylint dann auch jedesmal aufregt).
ACK. (vor allem: {}.has_key vs. __builtins__.hasattr)
Zudem: warum gibt es callable(obj) als Synonym zu hasattr(obj,'__call__'),
aber z.B. nicht lenable (oder so), um die Präsenz von __len__ abzufragen?
Warum hat dict ein clear(), list aber nicht?
Warum muß der Handler, der an codecs.register_error() ein Replacement vom
Typ unicode zurückgeben (IIRC), auch wenn es sich um einen Encode-Fehler
handelt?
So ganz konsistent ist Python wirklich nicht.
Thomas
--
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456
Ulf Kadner
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist.
Wie bereits in d.c.l.p.m erwähnt ist Deine Auflistung sinnfrei. Die
meisten Argumente sind keine. Auch wenn ich nicht immer mit PHP
zufrieden bin (ich bin seit nunmer fast 10 Jahren PHPler) kann ich kaum
einer Äußerung auf Deiner Webseite zustimmen.
Das was Du da so tust tut keiner der beiden Sprachen gut. Python hat
derartige Gabren genausowenig nötig wie PHP.
Nachdem Du nebenan in der PHP-NG nicht zuletzt durch Dein ignorantes
Auftreten für mächtig negative Wellen gesorgt hast, dachte ich
eigentlich Du hättest verstanden das Dein Ansinnen nicht im Sinne von
einem der beiden Vergleichsobjekte liegt.
> Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
Das steht ausser Frage. Um PHP zu ersetzen gibts auch "tausende" anderer
Sprachen.
Nur ums nochmal zu betonen. Auch Python hat fehler. Du tust ja bald so
als hättest Du den heiligen Gral in Python gefunden.
Alles hat Vorzüge und Nachteile. Aber Dein Listing ist sinnlos.
MfG, Ulf
Georg Brandl
> Sebastian Waschik wrote:
>
>> Du schreibst:
>>
>> |Mal werden die Teile des Namen mit Unterschrich getrennt und mal
>> |werden sie direkt aneinander gehängt
>>
>> Das hat doch python auch: has_key ist beispielsweise mit Unterstrich
>> und in unittest gibt es Methoden mit dem Namen setUp etc. (worüber
>> sich pylint dann auch jedesmal aufregt).
>
> ACK. (vor allem: {}.has_key vs. __builtins__.hasattr)
Bei "haskey" ist wohl für Englischsprache nicht so gut zu erkennen, worum es
sich handelt.
> Zudem: warum gibt es callable(obj) als Synonym zu hasattr(obj,'__call__'),
> aber z.B. nicht lenable (oder so), um die Präsenz von __len__ abzufragen?
Weil eben hasattr(obj, '__call__') nicht genügt. Klassen, die nicht für ihre
Instanzen __call__ definieren, haben kein __call__-Attribut, sind aber trotzdem
callable.
> Warum hat dict ein clear(), list aber nicht?
Weil für Listen Slicenotation existiert und das konsequent. => "del l[:]".
Genauso, wie man für Listen l.append(y) verwendet, für Dicts dagegen d[x] = y.
> Warum muß der Handler, der an codecs.register_error() ein Replacement vom
> Typ unicode zurückgeben (IIRC), auch wenn es sich um einen Encode-Fehler
> handelt?
>
> So ganz konsistent ist Python wirklich nicht.
Ohne Frage. 100%ige Konsistenz geht auf Kosten der Les- und Machbarkeit.
Georg
Volker Grabsch
> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
>
> http://helmbold.de/it/php/
Ich bin kein PHP-Fan, aber dieser Text hat mich überhaupt nicht
angesprochen. Einige unsachliche bzw. falsche Aussagen greife ich
mal heraus:
Du meinst sicher: "Ungeeignet für Web-Applikationen". Andere Vergleiche
wären nicht fair.
Da du php-gtk und ähnliches nicht betrachtest, solltest du IMHO klarer
herausstellen, dass du PHP nur für Web-Applikationen untersucht hast.
Schließlich behandelst du von den APIs her lediglich String-Verarbeitung,
Datenbank und HTML-Ausgabe/Templating.
(Ich will nicht sagen, dass PHP in anderen Bereichen besser abschneidet,
aber Tatsache ist nunmal, dass du in deinem Artikel auf nichts anderes
eingehst.)
| In anderen Sprachen (Python, Perl, Java...) ist es seit langem üblich,
| ein einheitliches API für den Zugriff auf Datenbanken zu verwenden. PHP
| dagegen bringt für sämtliche Datenbanken völlig unterschiedliche APIs
| mit.
Es gibt Pear::DB bzw. MDB2, die genau das leisten. Dass man in PHP
zusätzlich auch die mysql_*-Funktionen aufrufen kann, ist erstmal kein
Nachteil.
(Obwohl ich C oder C++ nehmen würde, wenn ich auf diesem niedrigen Level
arbeiten wollte, weil der einzige sinnvolle Grund dafür ein Performance-
Problem wäre.)
| Im Gegensatz zu (objektorientierten) Sprachen, die dem Stand der
| Technik entsprechen, kennt PHP keine Namensräume.
Was soll dieser Laber-Ballast?
"PHP kennt keine Namensräume."
Fertig. Namespaces sind schon seit 'zig Jahren Stand der Technik.
Und mit Objektorientierung hat das genau gar nichts zu tun.
| Die Syntax von PHP ist teilweise befremdlich: es gibt "=", "==" und
| auch noch "===".
Das ist ein sehr fadenscheiniges Argument. Was spielt die Syntax für
eine Rolle? Schlimm wäre es, wenn es *keine* Unterschiedung zwischen
Identität und Gleichheit gäbe. Auch die Dollars vor den Variablennamen
etc. sind mehr Geschmackssache als alles andere.
Dabon abgesehen: Auch in Python gibt es "=", "is" und "==".
Willst du ernst genommen werden, streiche solche Passagen einfach
heraus. Willst du hingegen flamen, dann streiche bitte alle Fakten
heraus und konzentriere dich voll und ganz auf Geschmacksfragen.
Der Mix von beidem ist nicht gut.
| Der Ausweg: Python
Es gibt auch innerhalb von PHP Auswege. Es gibt z.T. sehr gut
geschriebene PHP-Applikationen, auch wenn sie im Netz unter dem Müll
ersticken. Das ist aber ein anderes Problem, das Python bei dem
Bekanntheitsgrad ebenfalls hätte.
Nein, der springende Punkt ist, dass es *schwer* ist, sichere PHP-
Programme zu schreiben.
Andere Auswege sind: Java, LISP, Haskell, Ruby, Ocaml, u.s.w.
Besser:
"Ein Ausweg: Python"
Wobei ich nochmal betonen will, dass Programmierung in Python per
se auch nicht sicher ist. Den ganzen Quoting-Problemen wie in PHP
ist der Anfänger zwar nicht ausgesetzt, d.h. SQL-Injections etc.
sind unwahrscheinlicher. Dennoch behaupte ich, kein Neuling kann
nicht-trivial bombensichere Anwendungen schreiben, egal in welcher
Sprache, egal ob Webapplikation oder was anderes.
Der Ausweg heißt Kompetenz. Kompetenz über Sicherheit von Web-
Applikationen.
Hat man diese Kompetenz, kann man es sich schwer machen (PHP) oder
etwas leichter (Python). Hat man Hochsicherheits-Anforderungen, will
man es sich vielleicht noch etwas leichter machen (Ocaml, Haskell).
| Python ist vollständig dokumentiert.
Ist das ein Scherz? An etlichen Stellen ist PHP besser dokumentiert
als Python. Kommt immer drauf an, was man macht.
| Python ist performanter.
NACK. Gerade bei Web-Applikationen ist es PHP, der auf Performance
getrimmt ist. Außerdem sind solche Pauschal-Aussagen generell zu
belegen. Was für Programme wurden getestet? Welche Zeiten wurden
gemessen? Wie groß ist die Abweichung?
| Python ist durch und durch objektorientiert.
Gottseidank nicht. Hätte es nicht auch noch zahlreiche Features
von funktionalen Sprachen sowie ein dynamisches Typsystem, hätte
Python ähnliche Probleme wie Java, wo man selbst einfachste Konzepte
wie Callback nur auf umständlichem Wege ausdrücken kann.
Nein, Python ist nicht rein objektorientiert, und das ist auch gut so.
Es ist eine Multi-Paradigmen-Sprache, genau wie Ocaml, LISP, etc.
Iterator-Generatoren z.B. sind zum Glück nicht "rein objektorientiert"
realisiert worden. Und die Closures will ich auch nicht missen.
Mag sein, dass PHP zu wenige OO-Features hat und die paar, die es hat,
zu wenig einsetzt. Aber OO allein reicht trotzdem nicht, siehe Java.
"There is no Silver-Bullet."
| Python ermöglicht mit Threads verschiedene Aufgaben in einem Programm
| zu parallelisieren.
Python hat mit seinem GIL eine sehr primitive Thread-Implementierung.
Vielleicht ist das besser als in PHP, aber ich würde Threading in
Python nicht unbedingt hervorheben. Zumal es um Webapplikationen geht,
wo sich der App- oder Webserver um solche Details kümmert.
Ach ja, und am Anfang:
| Insbesondere bei kleinen und mittleren Websites hat die
| Programmiersprache PHP weite Verbreitung gefunden
Da ist dieses hässliche erste Wort. Es transportiert keinen Sinn und
stört beim Lesen. Du kannst es ersatzlos streichen.
Falls du dich über meinen Tonfall wunderst: Ich habe nur denselben
angeschlagen wie du in deinem Artikel. Wenn du das als störend und
verletztend empfindest, solltest du dies als Anlass nehmen, auch den
Tonfall deines Artikels zu überdenken. So viele überflüssige und
wertende Worte kannst du ersatzlos streichen, ohne dass dein Text an
Inhalt verliert. Im Gegenteil, er würde IMHO deutlich besser werden.
Viele Grüße,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Volker Grabsch
> Matthias Esken schrieb:
>
>> Als Entwickler, der mit PHP sehr vertraut ist und sich gerade Python
>> aneignet, kann ich den Punkt mit der schlechteren Dokumentation bei PHP so
>> nicht nachvollziehen. Für mich hat PHP eindeutig die bessere Dokumentation
>> mit schönen handlichen Beispielen.
>
> Großer Vorteil der Python-Doku ist, dass sie vollständig ist
Übersicht über Web-Frameworks?
Dokumentation der Templating-Systeme?
Man kann zwar argumentieren, dass dies alles "externe" Projekte sind,
und daher ihre eigene Doku haben. Aber das bestätigt umso mehr, dass
Python keine wirklich einheitliche Doku hat.
> und
> insgesamt nicht so chaotisch aussieht. Das bedeutet aber nicht, dass es
> da kein Verbesserungspotenzial gäbe.
PHP hat auch ne Menge Verbesserungspotenzial. ;-)
> Ein Freund schwärmt von der C#-
> bzw. .Net-Dokumentation; die könnte vielleicht als Vorbild dienen.
Auch die von Java ist nicht schlecht.
Volker Grabsch
>> im Absatz "Aufgesetzte Objektorientierung" schreibst Du
>> "entsteht auch bei eigentlich objektorientierten PHP-Programmen immer
>> ein Mischmasch aus objektorientierter und funktionaler Programmierung".
>>
>> Ich glaube, Du meinst hier "imperative Programmierung" anstatt
>> "funktionale Programmierung".
>
> Nein, eigentlich meint er wohl prozedurale Programmierung
> (also das, was man von Pascal kennt).
Oder auch "strukturierte Programmierung".
> Imperativ ist AFAIK eher ein Oberbegriff dazu
Ja.
Imperativer Stil vs. funktionaler Stil bezieht sich erstmal nur auf
vorhandene bzw. nicht-vorhandene Seiteneffekte.
Der Stil der objektorientieren Programmierung stützt sich sehr stark
auf Seiteneffekte. Man manipuliert ja ständig den internen Zustand
irgendeines Objektes, indem man ihm Botschaften sende (bzw. "Methoden
aufruft").
Zu den funktionalen Programmiersprachen gehört noch viel mehr, aber
der Begriff kommt daher, dass dieses Sprachen ursprünglich die ersten
waren, die Programmieren ohne Seiteneffekte praktikabel machten, und
sich dann mit zu den ausdrucksstärksten Sprachen weiterentwickelt haben.
Wobei das mit dem Begriffen immer so eine Sache ist. Sie wurden
ursprünglich definiert, um sich von etwas anderem abzusetzen. Das heißt,
sie werden durch das definiert, was sie *nicht* sein wollen. :-)
Prozedural/Strukturiert:
Kontrast zu Goto-Spaghetti-Code
Objektorientiert:
Funktionen und ihre Datenstrukturen sollen zusammenbleiben,
Polymorphie.
Kontrast zu strukturiertem Spaghetti-Code, der vor Switch-Anweisungen
strotzt.
Funktional:
Kontrast zu Code, in dem zu viele Seiteneffekte für Verwirrung
und Bugs sorgen.
Naja, und so weiter.
Martin Kaffanke
>> Großer Vorteil der Python-Doku ist, dass sie vollständig ist
>
> Übersicht über Web-Frameworks?
>
> Dokumentation der Templating-Systeme?
>
> Man kann zwar argumentieren, dass dies alles "externe" Projekte sind,
> und daher ihre eigene Doku haben. Aber das bestätigt umso mehr, dass
> Python keine wirklich einheitliche Doku hat.
Darüber hinaus bin ich immer wieder verwundert, warum hier so häufig das
Rad neu erfunden wird. Wir haben django, turbogears, pylons, wir haben
cherrypy, paste, colubrid, ... alles Dinge die letztlich eigentlich die
selben oder zumindest sehr ähnliche bereiche abdecken wollen.
Verschiedenste Dinge werden dann in den einelnen Dingen weiter selber
entworfen, während sqlalchemy zur verfügung steht, gibts in django und
sqlobject ähnliche Ziel, skeletonz hat dann überhaupt eine eigene
Datenbankschnittstelle, usw. usf.
Mir erscheint, als würden die Python Leute nicht miteinander arbeiten
wollen, nach außen wirkt das auf mich so, als würde jeder Python
Developer seinen eigenen Dickschädel haben und meinen er könnte es
besser als die anderen und entwickelt daraufhin eigene Module. Konsistenz
ist so überhaupt nicht möglich. Wenn sich das so weiterentwickelt, ist
in ein paar Jahren die Liste Ähnlicher module genauso lang wie ein modul
Quellcode hat.
Oder aber: Es ist nicht wirklich offensichtlich, wie man mit python am
besten an ein Problem heran gehen soll und erfindet deshalb verschiedene
Lösungen, bei denen letztlich nicht gesagt werden kann, was nun besser
ist. Es dominieren hauptsächlich Meinungen in Vergleichsdiskussionen,
tatsächliche Tests gibt es nur wenige.
Leider ist das aussuchen eines Frameworks, einer template engine, etc.
nicht so einfach wie Schuhe kaufen, man muss zuerst die Alternativen
anwenden können um dann für sich zu sagen: Das gefällt mir am besten.
lg,
Martin
Thomas Rachel
>> ACK. (vor allem: {}.has_key vs. __builtins__.hasattr)
>
> Bei "haskey" ist wohl für Englischsprache nicht so gut zu erkennen, worum
> es sich handelt.
Hm, wenn man es so bedenkt: Stimmt. (Ich las in Deinem Posting beim ersten
Mal "Haskell"...)
>> Zudem: warum gibt es callable(obj) als Synonym zu
>> hasattr(obj,'__call__'), aber z.B. nicht lenable (oder so), um die
>> Präsenz von __len__ abzufragen?
>
> Weil eben hasattr(obj, '__call__') nicht genügt. Klassen, die nicht für
> ihre Instanzen __call__ definieren, haben kein __call__-Attribut, sind
> aber trotzdem callable.
Ah, ok. Danke.
>> Warum hat dict ein clear(), list aber nicht?
>
> Weil für Listen Slicenotation existiert
Bekannt - aber...
> und das konsequent. => "del l[:]".
... diese Konsequenz war mir nicht bewußt - wieder was dazugelernt.
> Genauso, wie man für Listen l.append(y) verwendet, für Dicts dagegen d[x]
> = y.
BTW: Ist eigentlich
* l.append(el) *genau* dasselbe wie l += [el]? (zumindest vom Ergebnis her -
daß letzteres teurer ist als append, liegt nahe)
* l.extend(li) *genau* dasselbe wie l += li? (insbesondere, was den Typen
von y angeht - list, tuple, sonstige sequence, iterable, ...)
>> Warum muß der Handler, der an codecs.register_error() ein Replacement vom
>> Typ unicode zurückgeben (IIRC), auch wenn es sich um einen Encode-Fehler
>> handelt?
>>
>> So ganz konsistent ist Python wirklich nicht.
>
> Ohne Frage. 100%ige Konsistenz geht auf Kosten der Les- und Machbarkeit.
ACK, aber der letzte genannte Punkt wäre IMHO vermeidbar gewesen.
Ein Errorhandler sollte das, was zu ersetzen ist, unmittelbar zurückgeben.
Wenn ich einen Unicode-String in einen str encodieren will, und das geht so
nicht, dann sollte der Error-Handler die Ausgabe vorgeben, und nicht das,
was zu ersetzen wäre. Beim Decodieren ist es ja auch so.
Thomas
--
Kevin mit der Mami im Zoo vor dem Giraffenkäfig:
- Maaami, ein Haaase!
- Nein, Kevin, dieses ist kein Hase, dieses Tier ist eine Giraffe.
- So ein groosser Haaaase?
Volker Grabsch
>|Mal werden die Teile des Namen mit Unterschrich getrennt und mal
>|werden sie direkt aneinander gehängt
>
> Das hat doch python auch: has_key ist beispielsweise mit Unterstrich
> und in unittest gibt es Methoden mit dem Namen setUp etc. (worüber
> sich pylint dann auch jedesmal aufregt).
Weil unittest aus einer Java-Bibliothek kommt, und man vergessen hat,
die API pythonisch zu gestalten. Daher das CamelCase in den Methoden-
Namen und die umständliche Klassenhierarchie.
unittest sieht wie ein JUnit-Clone aus. Nicht nur die guten Ideen,
sondern auch die (wegen Java leider nötigen) Hässlichkeiten der API
wurde mit übernommen. Und das CamelCase.
pylint mackert zurecht. Pythons unittest hat ein API-Redesign dringend
nötig, und damit meine ich wiegesagt nicht nur das Umstellen der
Methoden-Namen.
Doch jetzt ist es zu spät. Interessant ist die Alternative py.test,
das ist wirklich schön und einfach, so wie's sein sollte.
Ich verwende deshalb in Python immer häufiger das Doctest-Modul. Da
kann ich meine Testfälle ohne den ganzen Overhead schreiben.
Überraschenderweise reicht das häufig, weil die interessanten Randfälle,
die ich per Unittest abfangen würde, sowieso auch in die Doku gehören.
Volker Grabsch
>> und das konsequent. => "del l[:]".
>
> ... diese Konsequenz war mir nicht bewußt - wieder was dazugelernt.
Ich mach immer: l[:] = []
Kommt aber aufs gleiche raus. :-)
Das "del" ist wahrscheinlich effizienter und auf jeden Fall besserer
Coding-Stil.
> BTW: Ist eigentlich
>
> * l.append(el) *genau* dasselbe wie l += [el]? (zumindest vom Ergebnis her -
> daß letzteres teurer ist als append, liegt nahe)
Ja. Aber
l = l + [el]
wäre was anderes, weil "l" dann seine Identität ändert, d.h. es wird
eine neue Liste erzeugt, statt die alte zu erweitern.
> * l.extend(li) *genau* dasselbe wie l += li? (insbesondere, was den Typen
> von y angeht - list, tuple, sonstige sequence, iterable, ...)
Ja. An der Stelle ist die API etwas komisch, das stimmt schon.
Johannes Veser
> "Johannes Veser" skribis:
>>
>> im Absatz "Aufgesetzte Objektorientierung" schreibst Du
>> "entsteht auch bei eigentlich objektorientierten PHP-Programmen immer
>> ein Mischmasch aus objektorientierter und funktionaler Programmierung".
>>
>> Ich glaube, Du meinst hier "imperative Programmierung" anstatt
>> "funktionale Programmierung".
>
> Nein, eigentlich meint er wohl prozedurale Programmierung
> (also das, was man von Pascal kennt).
Imperative und prozedurale Programmierung werden oft synonym gebraucht.
Wenn man es genau nimmt, hast Du aber Recht. Die Unterscheidung macht
Sinn :-). Ist bei mir schon länger her, dass ich mich mit
Programmier-Paradigmen also solchen beschäftigt hab. Prozedural rutscht
da öfters mal "unten durch".
> Imperativ ist AFAIK eher ein Oberbegriff dazu und
> auch in Python üblich, soweit ich das bisher
> beurteilen kann (bin Anfänger diesbezüglich) -
> kennzeichnend dafür ist die Verwendung von
> Statements (und nicht nur Expressions), und
> in der Python-Spezifikation wimmelt es nur so
> davon :-)
Ack. Wobei Python auch Anleihen bei anderen Paradigmen nimmt.
Gruß,
Johannes
Thomas Rachel
> Ich habe die Punkte warum ich von Perl nach Python
> umgestiegen bin aufgeschrieben:
>
>http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl2python
Anmerkung dazu:
os.system("gzip '%s'" % outfile)
kanllt, wenn outfile einen "'" enthält. Besser:
def shellquote(*strs):
r"""Input: Dateiname, output: String mit '' drumrum und jeder '
durch '\'' ersetzt. Zur Verwendung mit der Shell."""
# einfach alles außer ' übernehmen; ' ersetzen durch '\''
# ''' wird dadurch für die Shell zu ''\'''\'''\'''.
# Unschön, aber egal.
return " ".join([
"'"+st.replace("'","'\\''")+"'"
for st in strs
])
os.system("gzip %s" % shellquote(outfile))
Thomas
--
Roses are red. Violets are blue. Some poems rhyme. But this one doesn't.
Diez B. Roggisch
>>
>> Dokumentation der Templating-Systeme?
>>
>> Man kann zwar argumentieren, dass dies alles "externe" Projekte sind,
>> und daher ihre eigene Doku haben. Aber das bestätigt umso mehr, dass
>> Python keine wirklich einheitliche Doku hat.
>
> Darüber hinaus bin ich immer wieder verwundert, warum hier so häufig das
> Rad neu erfunden wird. Wir haben django, turbogears, pylons, wir haben
> cherrypy, paste, colubrid, ... alles Dinge die letztlich eigentlich die
> selben oder zumindest sehr ähnliche bereiche abdecken wollen.
> Verschiedenste Dinge werden dann in den einelnen Dingen weiter selber
> entworfen, während sqlalchemy zur verfügung steht, gibts in django und
> sqlobject ähnliche Ziel, skeletonz hat dann überhaupt eine eigene
> Datenbankschnittstelle, usw. usf.
<snip/>
Ich halte das fuer nicht besonders sinnovoll, was du hier sagst. Aus einem
ganz einfachen Gruenden: Python ist im Gegensatz zu PHP eine
general-purpose Sprache, und Proliferation ist gut.
Ersteres liegt auf der Hand - die erste Zeile PHP die jemand schreiben
_will_, laeuft in einem Apache und wird durch einen Browser getriggert.
Kein Wunder, das es da einen "Vorsprung" hat.
Aber schon auf der naechsten Ebene kann man genauso ansetzen: warum gibt es
Joomla, Mango, Typo3 und was weiss ich wie all die CMSse heissen? Ganz
einfach: nicht jeder Deckel passt auf jeden Topf. Und selbiges gilt auch
fuer Webframeworks.
Womit wir schon beim zweiten Punkt sind. Nur wenn Ideen miteinander
konkurrieren, koennen sich wirklich neue Dinge entwickeln. Schau dir nur
mal an, was fuer ein Horror die Java J2EE-Specifikationen sind. Nimm zB EJB
2.x als Standard fuer Persistenz. Langsam, aufgeblasen, der reine Horror.
Alles entwickelt sich nur durch Gremienbeschluesse, mit politischen
Raenkespielen usw. Und es hat Jahre gedauert, bis sich mit EJB3.0 und JDO
neue Standards etabliert haben - aber auch die sind nicht immer das gelbe
vom Ei.
Dahingegen loesen SQLAlchemy und SQLObject aehnliche Probleme auf
unterschiedliche Weise - jedes mit seinen Staerken und Schwaechen. Ich zB
bevorzuge SQLObject. SA ist mir zu verbos. Dafuer nehme ich (sehr gerne
sogar) in Kauf, das meine SQL-Daten-Schemata rigider sind.
Gleiches gilt im Webframework-Umfeld. Mir gefaellt Turbogears, aber je nach
Einsatzzweck mag Django oder gar was ganz anderes besser sein.
Ich bin kein Feind von Standards. Aber sie muessen sich aus Erfahrung
bilden, und das bedeutet nunmal wildwuchs, zumindest eine Weile lang.
Wenn man deine Argumentation durchzieht, dann arbeiten wir alle auf Windows,
mit einer Oracle-Datenbank, unter ASP.NET. Danke, aber nicht mit mir....
MfG Diez
Marc 'BlackJack' Rintsch
wrote:
> | Python ist durch und durch objektorientiert.
>
> Gottseidank nicht.
$GOTT sei Dank *doch*.
> Hätte es nicht auch noch zahlreiche Features von funktionalen Sprachen
> sowie ein dynamisches Typsystem, hätte Python ähnliche Probleme wie
> Java, wo man selbst einfachste Konzepte wie Callback nur auf
> umständlichem Wege ausdrücken kann.
Das liegt nicht an OO sondern daran, dass Java so unverhältnismässig
viel Wert auf Klassen legt. Für OO braucht man streng genommen
überhaupt keine Klassen, Objekte reichen. Wie man z.B. an "reinen"
OO-Sprachen wie Io sehen kann. Typsystem (dynamisch/statisch) und die
Existenz höherer Funktionen und syntaktischem Zucker wie
List-Comprehension oder Generator-Funktionen ändern nichts daran, dass in
Python alles Objekt ist.
Ciao,
Marc 'BlackJack' Rintsch
Martin Kaffanke
> Ich halte das fuer nicht besonders sinnovoll, was du hier sagst. Aus einem
> ganz einfachen Gruenden: Python ist im Gegensatz zu PHP eine
> general-purpose Sprache, und Proliferation ist gut.
Ja, stimmt im Grunde schon, aber gerade wenn man sein erstes Web-Projekt
schreibt, ist es fast nicht möglich sich für eine framework zu
entscheiden, ohne dabei eine Woche Arbeitszeit zu investieren.
Vielleicht sollte gerade hier eine bessere Vergleichende Dokumentation
gemacht werden?
lg,
Martin
Marc 'BlackJack' Rintsch
wrote:
>>> Ich glaube, Du meinst hier "imperative Programmierung" anstatt
>>> "funktionale Programmierung".
>>
>> Nein, eigentlich meint er wohl prozedurale Programmierung
>> (also das, was man von Pascal kennt).
>
> Oder auch "strukturierte Programmierung".
Das trifft aber IMHO auch auf Python zu. Damit verbinde ich Struktogramme
und keine GOTOs. Ausser man argumentiert, dass Ausnahmen die
strukturierte Programmierung wieder "kaputt machen". Andererseits kennt
auch die Vorzeigesprache Pascal für strukturierte Programmierung noch ein
GOTO.
Ciao,
Marc 'BlackJack' Rintsch
Georg Brandl
> Thomas Guettler wrote:
>
>> Ich habe die Punkte warum ich von Perl nach Python
>> umgestiegen bin aufgeschrieben:
>>
>>http://www.thomas-guettler.de/vortraege/programmierung/einfuehrung.html#perl2python
>
> Anmerkung dazu:
>
> os.system("gzip '%s'" % outfile)
>
> kanllt, wenn outfile einen "'" enthält. Besser:
>
> def shellquote(*strs):
> r"""Input: Dateiname, output: String mit '' drumrum und jeder '
> durch '\'' ersetzt. Zur Verwendung mit der Shell."""
> # einfach alles außer ' übernehmen; ' ersetzen durch '\''
> # ''' wird dadurch für die Shell zu ''\'''\'''\'''.
> # Unschön, aber egal.
> return " ".join([
> "'"+st.replace("'","'\\''")+"'"
> for st in strs
> ])
> os.system("gzip %s" % shellquote(outfile))
"Ganz schlaue" verwenden
os.environ['gzip_outfile'] = outfile
os.system('gzip "$gzip_outfile"')
und lassen die Shell den Rest erledigen.
Georg
Volker Grabsch
> In <slrnereoic.ef7...@localhost.localnet>, Volker Grabsch wrote:
>>>> Ich glaube, Du meinst hier "imperative Programmierung" anstatt
>>>> "funktionale Programmierung".
>>>
>>> Nein, eigentlich meint er wohl prozedurale Programmierung
>>> (also das, was man von Pascal kennt).
>>
>> Oder auch "strukturierte Programmierung".
>
> Das trifft aber IMHO auch auf Python zu.
Ja, das ist wahr. OO setzt auf die strukturierte Programmierung auf.
> Damit verbinde ich Struktogramme und keine GOTOs.
Hab nichts anderes behauptet.
Volker Grabsch
> wrote:
>
>> | Python ist durch und durch objektorientiert.
>>
>> Gottseidank nicht.
>
> $GOTT sei Dank *doch*.
> ändern nichts daran, dass in Python alles Objekt ist.
So gesehen ja. Ich wollte nur klarstellen, dass die Python-API
nicht allein mit OO-Paradigmen designt wurde, sondern dass noch
etwas mehr dahinter steckt.
Volker Grabsch
> Thomas Rachel schrieb:
>> os.system("gzip %s" % shellquote(outfile))
>
> "Ganz schlaue" verwenden
>
> os.environ['gzip_outfile'] = outfile
> os.system('gzip "$gzip_outfile"')
Mal ehrlich: Das ist doch beides Käse.
Ich finde, Escaping ist ein Implementierung-Detail. Eine API sollte so
gebaut sein, dass sie auch "unsichere" Strings entgegen nehmen kann.
(lies: beliebige Strings)
Der User sollte niemals selbst quoten müssen.
Bei Datenbank-APIs bedeutet dies, etwas wie "SELECT ... WHERE id=?"
zu ermöglichen, und die Parameter separat mitzugeben.
Bei XML-APIs bedeutet es, dass man xml.sax.XmlWriter oder einen DOM
nimmt.
Bei Shell-Aufrufen bedeutet es, dass man die Argumente gleich als Array
übergibt. Besonders schön geht das mit subprocess:
from subprocess import Popen
Popen(["gzip", outfile])
Wobei nichts über eine direkte API geht, hier also konkret eine gzip-
Funktion in Python.
Anmerkung: Das mit der Shell stimmt nicht ganz. Man muss auch
sicherstellen, dass die Argumente keine weiteren Optionen darstellen.
Das erreicht man am einfachsten, indem man die Optionsliste explizit
mit "--" beendet, z.B.
Popen(["gzip", "--", outfile])
os.system() ist grundsätzlich zu vermeiden.
Georg Brandl
> Georg Brandl <g.brand...@gmx.net> schrieb:
>> Thomas Rachel schrieb:
>>> os.system("gzip %s" % shellquote(outfile))
>>
>> "Ganz schlaue" verwenden
>>
>> os.environ['gzip_outfile'] = outfile
>> os.system('gzip "$gzip_outfile"')
>
> Mal ehrlich: Das ist doch beides Käse.
Deswegen auch die Anführungszeichen.
(das Django-Team gehört hier zu den "schlauen"...)
Georg
Christian Helmbold
> Falls du dich über meinen Tonfall wunderst: Ich habe nur denselben
> angeschlagen wie du in deinem Artikel. Wenn du das als störend und
> verletztend empfindest, solltest du dies als Anlass nehmen, auch den
> Tonfall deines Artikels zu überdenken.
So empfindlich bin ich nicht, aber ich danke dir auf jeden Fall für
deine Kritik! Statt dem was, nebenan in der PHP-Gruppe gebracht wurde,
hat dein Beitrag Substanz. Bei Gelegenheit werde ich meinen Text
überarbeiten.
Gruß
Christian
--
E-Mails werden nur mit Glück gelesen.
Schönschrift für Mails: "Bitstream Vera Sans Mono"
http://www.gnome.org/fonts/
Volker Grabsch
> Hallo Volker,
>
>> Falls du dich über meinen Tonfall wunderst: Ich habe nur denselben
>> angeschlagen wie du in deinem Artikel. Wenn du das als störend und
>> verletztend empfindest, solltest du dies als Anlass nehmen, auch den
>> Tonfall deines Artikels zu überdenken.
>
> So empfindlich bin ich nicht, aber ich danke dir auf jeden Fall für
> deine Kritik! Statt dem was, nebenan in der PHP-Gruppe gebracht wurde,
> hat dein Beitrag Substanz.
Mag sein, aber ein guter Schreiber kommt mit *allein* mit Substanz aus.
Ein besserer Schreiber packt Scherze und Aufmunterungen hinein, um es
angenehmer und unterhaltsamer für den Leser zu machen.
Aber das Stilmittel des Niedermachens hat nur ganz selten eine Daseins-
berechtigung. In deinem konkreten Fall war es nicht nur überflüssig,
sondern sogar kontraproduktiv.
Das einzig gute an diesem Ballast ist, dass er dich überhaupt zum Schreiben
gebracht hat. Nun, wo der Artikel da steht, kannst du den Ballast wieder
rauswerfen. Dein Artikel braucht ihn nicht, er wird ohne ihn sehr viel an
Qualität gewinnen.
> Bei Gelegenheit werde ich meinen Text überarbeiten.
Ich empfehle dringend, den Text vom Netz zu nehmen, bis er überarbeitet
ist. Nichts für ungut, aber die Empörung ist nunmal gerechtfertigt, das
attestieren dir sowohl die Python- als auch die PHP-Gruppe.
Danach könntest du ihn nochmal hier ankündigen. Du wirst sehr viel mehr
substanzielle Kritik erhalten, weil dein Artikel selbst zu einem höheren
Anteil aus Substanz bestehen wird.
Matthias Esken
> So empfindlich bin ich nicht, aber ich danke dir auf jeden Fall für
> deine Kritik! Statt dem was, nebenan in der PHP-Gruppe gebracht wurde,
> hat dein Beitrag Substanz.
Na ja, wenn man als Harley-Fahrer in eine Kneipe mit Mofafahrern geht und
schreit "Ihr seid alles Vollidioten!" muss man mit Gegenwind rechnen.
Gruß,
Matthias
Thomas Rachel
> Georg Brandl <g.brand...@gmx.net> schrieb:
>> Thomas Rachel schrieb:
>>> os.system("gzip %s" % shellquote(outfile))
>>
>> "Ganz schlaue" verwenden
>>
>> os.environ['gzip_outfile'] = outfile
>> os.system('gzip "$gzip_outfile"')
>
> Mal ehrlich: Das ist doch beides Käse.
Kommt drauf an, auf welchem Abstraktionslevel.
> Ich finde, Escaping ist ein Implementierung-Detail. Eine API sollte so
> gebaut sein, dass sie auch "unsichere" Strings entgegen nehmen kann.
> (lies: beliebige Strings)
> Der User sollte niemals selbst quoten müssen.
ACK. Zumindest dort, wo die Funktion letztendlich aufgerufen wird. Was eine
Stufe weiter unten passiert, ist nochmal eine andere Sache.
Ich habe mir subprocess mal angeschaut - ja, stimmt, das ist wirklich schön.
Kannte ich noch gar nicht. (Gibts leider erst seit 2.4; wenn man auf 2.3
angewiesen ist, muß man eben doch auf "alte" Sachen zurückgreifen.)
Unsauber programmiert ist es aber (hier: 2.4):
>>> a=subprocess.Popen(('echo "$@"','-','1','2'),shell=True)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/subprocess.py", line 554, in __init__
errread, errwrite)
File "/usr/lib/python2.4/subprocess.py", line 903, in _execute_child
args = ["/bin/sh", "-c"] + args
TypeError: can only concatenate list (not "tuple") to list
Laut der Doku erwartete ich eigentlich, eine beliebige Sequence übergeben zu
können; Zeile 903 sollte IMHO lauten 'args = ["/bin/sh", "-c"] +
list(args)'
> Wobei nichts über eine direkte API geht, hier also konkret eine gzip-
> Funktion in Python.
Full ACK. Ob diese dann als C-Modul implementiert ist (was Du vermutlich
meintest) oder aber /usr/bin/gzip wahlweise über os.system() oder
supprocess.Popen aufruft und dort dann anständig escaped, ist ein
Implementierungsdetail, das den Aufruder von gzip() nicht zu interessieren
braucht.
> Anmerkung: Das mit der Shell stimmt nicht ganz. Man muss auch
> sicherstellen, dass die Argumente keine weiteren Optionen darstellen.
> Das erreicht man am einfachsten, indem man die Optionsliste explizit
> mit "--" beendet, z.B.
>
> Popen(["gzip", "--", outfile])
s/outfile/infile/
Stimmt, "--" wird gern vergessen.
> os.system() ist grundsätzlich zu vermeiden.
Geht nicht immer. (s.o., Python 2.3) Ok, man kann sich natürlich was Eigenes
mit Hilfe von execvp, fork etc. basteln, aber wenn man gescheit quotet,
funktioniert os.system() IMHO genausogut.
Hinzu kommt: wenn man eine Funktion zur Ausfürung eines Prorgammes auf einem
anderen Rechner via ssh schreiben will, kommt man um entsprechendes Quoting
ebenfalls nicht herum, und da gibt es zu meiner vorgestellten Funktion
schlichtweg keine Alternativen, weil ssh (vermutlich aus
Kompatibilitätsgründen zu rsh) leider einfach alle Argumente zusammenkettet
und sie der remote-Shell übergibt, anstatt alles ab dem zweiten als
Parameter zu verwenden. Unschön, aber nicht zu ändern.
Thomas
--
Eine Klick-Mich-Ich-Bin-Der-Fruehling-Loesung gibt es nicht, ein *bisschen*
Eigeninitiave braucht es immer. (Ulli Horlacher in dan-a.mail)
Volker Grabsch
> Volker Grabsch wrote:
>> Georg Brandl <g.brand...@gmx.net> schrieb:
>
>>>> a=subprocess.Popen(('echo "$@"','-','1','2'),shell=True)
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "/usr/lib/python2.4/subprocess.py", line 554, in __init__
> errread, errwrite)
> File "/usr/lib/python2.4/subprocess.py", line 903, in _execute_child
> args = ["/bin/sh", "-c"] + args
> TypeError: can only concatenate list (not "tuple") to list
>
> Laut der Doku erwartete ich eigentlich, eine beliebige Sequence übergeben zu
> können; Zeile 903 sollte IMHO lauten 'args = ["/bin/sh", "-c"] +
> list(args)'
ACK. Du hast einen Bug gefunden. Trage ihn doch mal dem Python-Projekt
vor, indem du z.B. den einen Patch fertig stellst oder es zumindest in
deren Mailingliste/Bugtracker vorträgst.
Oder, wenn du diesen Aufwand nicht treiben möchtest, übersetze deinen
Erklärungs-Text doch bitte ins Englische und poste nach comp.lang.python,
das wäre super.
>> os.system() ist grundsätzlich zu vermeiden.
>
> Geht nicht immer. (s.o., Python 2.3) Ok, man kann sich natürlich was Eigenes
> mit Hilfe von execvp, fork etc. basteln, aber wenn man gescheit quotet,
> funktioniert os.system() IMHO genausogut.
Nein, auch hier gibt's noch weitere Möglichkeiten, die gern vergessen
werden. Die Unix-Klassiker, die zwar stdin und stdout umleiten, aber
dafür auch in C/C++ praktikabler als execvp+fork sind:
os.popen2
os.popen3
Oder spezielle Python-Funktionen, die es auch schon in 2.3 gibt:
os.spawnv
os.spawnve
os.spawnvp
os.spawnvpe
Die bauen allesamt Subprozesse auf und können allesamt die Argumente
einzeln bekommen. Das Modul "subprocess" fasst all diese Möglichkeiten
einfach nochmal zusammen zu einer einzigen konsistenten Schnittstelle.
Auszug aus der Doku von os.spawnv:
spawnv(mode, file, args)
spawnv(mode, file, args) -> integer
Execute file with arguments from args in a subprocess.
If mode == P_NOWAIT return the pid of the process.
If mode == P_WAIT return the process's exit code if it exits normally;
otherwise return -SIG, where SIG is the signal that killed it.
Das hast du gesucht, oder?
import os
os.spawnv(os.P_WAIT, "/usr/bin/gzip", ["/usr/bin/gzip", "--", infile])
> Hinzu kommt: wenn man eine Funktion zur Ausfürung eines Prorgammes auf einem
> anderen Rechner via ssh schreiben will, kommt man um entsprechendes Quoting
> ebenfalls nicht herum,
ACK. Diesen Probleme begegne ich persönlich aber lieber dadurch, dass
ich auf dem Zielrechner ein entsprechendes (Python- oder Shell-) Script
schreibe und dieses einfach aufrufe. Parameter kann ich dann über Stdin
übergeben, brauch ich aber meistens eh nicht.
> und da gibt es zu meiner vorgestellten Funktion
> schlichtweg keine Alternativen, weil ssh (vermutlich aus
> Kompatibilitätsgründen zu rsh) leider einfach alle Argumente zusammenkettet
> und sie der remote-Shell übergibt, anstatt alles ab dem zweiten als
> Parameter zu verwenden. Unschön, aber nicht zu ändern.
Das stimmt. Hab ich aber noch nie in der Form gebraucht. Wofür brauchst
du denn sowas?
Georg Brandl
> Thomas Rachel <glg...@expires-2007-02-28.arcornews.de> schrieb:
>> Volker Grabsch wrote:
>>> Georg Brandl <g.brand...@gmx.net> schrieb:
>> Unsauber programmiert ist es aber (hier: 2.4):
>>
>>>>> a=subprocess.Popen(('echo "$@"','-','1','2'),shell=True)
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>> File "/usr/lib/python2.4/subprocess.py", line 554, in __init__
>> errread, errwrite)
>> File "/usr/lib/python2.4/subprocess.py", line 903, in _execute_child
>> args = ["/bin/sh", "-c"] + args
>> TypeError: can only concatenate list (not "tuple") to list
>>
>> Laut der Doku erwartete ich eigentlich, eine beliebige Sequence übergeben zu
>> können; Zeile 903 sollte IMHO lauten 'args = ["/bin/sh", "-c"] +
>> list(args)'
>
> ACK. Du hast einen Bug gefunden. Trage ihn doch mal dem Python-Projekt
> vor, indem du z.B. den einen Patch fertig stellst oder es zumindest in
> deren Mailingliste/Bugtracker vorträgst.
>
> Oder, wenn du diesen Aufwand nicht treiben möchtest, übersetze deinen
> Erklärungs-Text doch bitte ins Englische und poste nach comp.lang.python,
> das wäre super.
Nicht nötig, das ist in Subversion schon gefixt (bug #1357915).
Georg
Paul Ebermann
> Volker Grabsch wrote:
>
> > Wobei nichts über eine direkte API geht, hier also konkret eine gzip-
> > Funktion in Python.
>
> Full ACK. Ob diese dann als C-Modul implementiert ist (was Du vermutlich
> meintest) oder aber /usr/bin/gzip wahlweise über os.system() oder
> supprocess.Popen aufruft und dort dann anständig escaped, ist ein
> Implementierungsdetail, das den Aufruder von gzip() nicht zu interessieren
> braucht.
Hmm, ich hätte jetzt gedacht, da wäre
gzip in Python implementiert :-)
Oder wäre das dann wieder zu langsam?
Paul
--
Nun ludigxas: Kore: Pasanta Pasio (Kia Viv')
Christian Helmbold
> Na ja, wenn man als Harley-Fahrer in eine Kneipe mit Mofafahrern geht und
> schreit "Ihr seid alles Vollidioten!" muss man mit Gegenwind rechnen.
Ok, ich hatte schon nicht damit gerechnet, dass sie in Jubel ausbrechen,
aber die Kritik dort war weitestgehend substanzlos. Mir wurde alles
mögliche vorgeworfen, aber es kam keine konkrete Kritik zu den Aussagen
über PHP.
Thomas Rachel
> ACK. Du hast einen Bug gefunden. Trage ihn doch mal dem Python-Projekt
> vor, indem du z.B. den einen Patch fertig stellst oder es zumindest in
> deren Mailingliste/Bugtracker vorträgst.
>
> Oder, wenn du diesen Aufwand nicht treiben möchtest, übersetze deinen
> Erklärungs-Text doch bitte ins Englische und poste nach
> comp.lang.python, das wäre super.
Hat sich ja offenbar erledigt - danke, Georg.
> Nein, auch hier gibt's noch weitere Möglichkeiten, die gern vergessen
> werden. Die Unix-Klassiker, die zwar stdin und stdout umleiten, aber
> dafür auch in C/C++ praktikabler als execvp+fork sind:
>
> os.popen2
> os.popen3
>
> Oder spezielle Python-Funktionen, die es auch schon in 2.3 gibt:
>
> os.spawnv
> os.spawnve
> os.spawnvp
> os.spawnvpe
>
> Die bauen allesamt Subprozesse auf und können allesamt die Argumente
> einzeln bekommen.
stdin/out/err muß ich aber immer noch manuell umleiten. Und bei den
popen-Funktionen gibt es AFAIR mindestens eine, die eben doch keine
Parameterliste entgegennimmt. (Weiß nicht mehr, welche das war...
os.popen, glaube ich)
Ich hab mir da mal was gestrickt durch Anpassen von popen.py - das hat
man aber auch nicht immer zur Verfügung, vor allem, wenn man was zur
Veröffentlichung vorgesehenes basteln will. (Was ich kurzfristig
allerdings nicht vorhabe; ich versuche jedoch möglichst so zu
programmieren, daß es möglich wäre.)
> Das hast du gesucht, oder?
>
> import os
> os.spawnv(os.P_WAIT, "/usr/bin/gzip", ["/usr/bin/gzip", "--",
> infile])
Wie würde ich damit gzip(str) implementieren zur Komprimierung der Daten
im String str()? (Nein, temporäre Datei ist schlecht.)
Das Modul popen2 geht auch nur ab 2 aufwärts (also popen[234], nicht
jedoch popen).
Wie gesagt, am saubersten ist es wohl, das mit os.fork, os.dup2 und eben
doch os.exec* so nachzubilden, wie man es braucht. Aber oft scheint
einem der Aufwand zu hoch.
Was spricht denn konkret gegen ein Quoten aller Zeichen außer dem "'"
durch Umschließen mit demselben und einem Quoten des "'" mit einem r"\"
davor? (außer daß es Overhead ist, da ja 3 Ebenen untendrunter eben doch
mit execv gearbeitet wird)
>> Hinzu kommt: wenn man eine Funktion zur Ausfürung eines Prorgammes auf
>> einem anderen Rechner via ssh schreiben will, kommt man um
>> entsprechendes Quoting ebenfalls nicht herum,
>
> ACK. Diesen Probleme begegne ich persönlich aber lieber dadurch, dass
> ich auf dem Zielrechner ein entsprechendes (Python- oder Shell-) Script
> schreibe und dieses einfach aufrufe. Parameter kann ich dann über Stdin
> übergeben, brauch ich aber meistens eh nicht.
Wäre auch eine Möglichkeit, sicherlich. Kommt wohl auf den Einzelfall an.
Wenn ich per stdin Nutzdaten übertragen will, wird das u.U. knifflig...
> Hab ich aber noch nie in der Form gebraucht. Wofür brauchst du denn
> sowas?
Momentan nix Konkretes; es ging mir in erster Linie um die Machbarkeit.
Thomas
--
Es klopft an der Tür. Kevin geht hin:
- Wer ist daaa?
- Ich.
- Iiich?
Ulf Kadner
> Ok, ich hatte schon nicht damit gerechnet, dass sie in Jubel ausbrechen,
> aber die Kritik dort war weitestgehend substanzlos.
Nein Du hast die Kritiken einfach nur Ignoriert oder auch garnicht erst
verstanden. Keiner macht sich freiwillig die Arbeit Deinen Kram in Lot
zu bringen wenn Du in keiner Weise einlenken willst.
Ulf
Daniel
"Christian Helmbold" <c.hel...@gmx.de> schrieb im Newsbeitrag
news:45b7...@news.arcor-ip.de...
Hallo Christian,
> Ok, ich hatte schon nicht damit gerechnet, dass sie in Jubel ausbrechen,
> aber die Kritik dort war weitestgehend substanzlos.
Oh je, lass das bloß nicht die anderen hier lesen, sonst wirst Du noch aus
der Newsgroup geschmissen und automatisch nach de.comp.lang.php.misc
weitergeleitet :-P
> Mir wurde alles
> mögliche vorgeworfen, aber es kam keine konkrete Kritik zu den Aussagen
> über PHP.
Dazu gibt es einen guten Spruch: Diskutiere nie mit Idioten! Erst ziehen sie
Dich auf ihr Niveau herab, dann schlagen sie Dich mit geballter Erfahrung.
Hinsichtlich diverser Inkonsistenzen bei Funktionsnamen und Parameterlisten
haben Dir die meisten wohl recht gegeben, weil dies so ist. Alles andere,
was Du in Deinem Pamphlet ausgekotzt hast, ließ vorrangig auf zu wenig
Kompetenz oder zu wenig Erfahrung mit PHP schließen, da man mit ein wenig
Erfahrung mit einer Handvoll Funktionen die angesprochenen Kritikpunkte mit
Leichtigkeit umschiffen kann. Im Übrigen fehlte nicht nur eine ausgewogene
Betrachtung von PHP inklusive der Vorteile, sondern auch Beispiele für
Pythons vermeintliche Überlegenheit oder generell eine konkretere
Gegenüberstellung von einzelnen Features in PHP und Python. Ansonsten sei
nur noch soviel gesagt, dass Programmiersprachen zum Schwanzvergleich nicht
taugen: "Meiner ist größer, ich programmier in Python..." Dafür gibt es "Am
I sexy?" und ähnliche Sites.
MfG
Daniel
Marek Kubica
On Thu, 25 Jan 2007 13:03:57 +0100, Thomas Rachel wrote:
>> os.system() ist grundsätzlich zu vermeiden.
>
> Geht nicht immer. (s.o., Python 2.3) Ok, man kann sich natürlich was Eigenes
> mit Hilfe von execvp, fork etc. basteln, aber wenn man gescheit quotet,
> funktioniert os.system() IMHO genausogut.
Don't fear - subprocess gibt es sogar für Python 2.2:
http://effbot.org/downloads/#subprocess
Und wer Python 2.1 einsetzt ist selbst schuld und hat die letzten paar
Jahre gut geschlafen ;)
grüße,
Marek
Marek Kubica
On Wed, 24 Jan 2007 15:51:03 +0100, Martin Kaffanke wrote:
> Ja, stimmt im Grunde schon, aber gerade wenn man sein erstes Web-Projekt
> schreibt, ist es fast nicht möglich sich für eine framework zu
> entscheiden, ohne dabei eine Woche Arbeitszeit zu investieren.
Na, das ist doch bei allem so. Wenn ich eine Programmiersprache suche,
dann gucke ich was es auf dem Markt gibt. Wenn ich ein CMS suche - ebenso.
Warum sollte es dann das eine, richtige, Framework dann geben? Selbst PHP
hat mehrere.
> Leider ist das aussuchen eines Frameworks, einer template engine, etc.
> nicht so einfach wie Schuhe kaufen, man muss zuerst die Alternativen
> anwenden können um dann für sich zu sagen: Das gefällt mir am besten.
Also ich probiere Schuhe auch an (=wende sie an), vergleiche sie mit
Alternativen.. ähm, anderen Schuhen und wähle aus, welche mir am besten
gefallen. Optimal auch, wenn sie mir passen.
Ergo: Framework-Aussuchen istn fast wie Schuhekaufen (sogar noch besser,
weil es die Frameworks i.d.R. umsonst gibt, also kann man problemlos
mehrere "kaufen").
grüße,
Marek
Martin Kaffanke
>> Leider ist das aussuchen eines Frameworks, einer template engine, etc.
>> nicht so einfach wie Schuhe kaufen, man muss zuerst die Alternativen
>> anwenden können um dann für sich zu sagen: Das gefällt mir am besten.
> Also ich probiere Schuhe auch an (=wende sie an), vergleiche sie mit
> Alternativen.. ähm, anderen Schuhen und wähle aus, welche mir am besten
> gefallen. Optimal auch, wenn sie mir passen.
> Ergo: Framework-Aussuchen istn fast wie Schuhekaufen (sogar noch besser,
> weil es die Frameworks i.d.R. umsonst gibt, also kann man problemlos
> mehrere "kaufen").
Ok, dann fehlt nur noch der Leitfaden, wie man in weniger als 5 Minuten
weiß ob einem ein Framework gefällt oder nicht.
lg,
Martin
Martin Schuette
> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
> PHP in der Regel ganz gut durch Python ersetzen können müsste.
Hallo,
ich möchte die Gelegenheit nutzen um einmal eine ganz praktische Frage
anzubringen:
Kann ich als Admin eines Webservers das Benutzen von Python anbieten,
dabei aber wie beim PHP safe-mode gewisse Sicherheitsrichtlinien
(keine Shell, Zugriff nur auf's eigene Verzeichnis) gewährleisten?
In der Doku zu mod_python habe ich dazu nichts gefunden.
--
Martin
Stefan Scholl
> Kann ich als Admin eines Webservers das Benutzen von Python anbieten,
> dabei aber wie beim PHP safe-mode gewisse Sicherheitsrichtlinien
> (keine Shell, Zugriff nur auf's eigene Verzeichnis) gewährleisten?
> In der Doku zu mod_python habe ich dazu nichts gefunden.
Zu mod_python und Apache kann ich Dir in dieser Hinsicht nichts
sagen, aber um Python zu hosten benötigt man nicht unbedingt
mod_python.
Es gibt einige Hoster die z. B. FastCGI (oder SCGI) anbieten. Die
Programme Deiner User kannst Du mit dieser Methode unter einem
eigenen User-Account des Servers laufen lassen.
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
Diez B. Roggisch
Warum willst du das in weniger als 5min wissen? Ich verstehe dieses
Getue darum, was nun das beste waere nicht.
Nimm, womit du gut klarkommst. Das es da draussen noch etwas
anderes/besseres geben koennte - Geschenkt! Wenn du die Zeit hast,
schau's dir mal an. Oder wenn du merkst, das du nicht weiterkommst.
Aber es gibt nicht *DAS* Framework, und in dem Moment kannst du eben
"einfach" eines auswaehlen. Die beiden grossen im Python-Bereich (ZOPE
mal kurz aussen vor), TurboGears & Django, haben 20min Tutorials. Willst
du mir sagen, das du nicht 40 min opfern kannst (oder 10, beide
durchzulesen) und dir eine Meinung bilden was dir irgendwie klarer
erscheint?
Als Programmierer musst du eh dauernd Entscheidungen treffen, die sich
im Nachhinein als schwierig oder gar dramatisch falsch herausstellen.
That's life.
Was nicht heisst, das eine Uebersicht ueber bestimmte Staerken und
Schwaechen nicht nett sei - aber Vorraussetzung fuer eine Entscheidung
ist sie nich.
diez
Martin Kaffanke
>> Ok, dann fehlt nur noch der Leitfaden, wie man in weniger als 5 Minuten
>> weiß ob einem ein Framework gefällt oder nicht.
>
> Warum willst du das in weniger als 5min wissen? Ich verstehe dieses
> Getue darum, was nun das beste waere nicht.
Naja, da gings vor allem um den Vergleich Schuhe Kaufen und Framework
aussuchen.
Am liebsten wäre wir, wenn Expertenentscheidungen vorliegen, die objektiv
die Frameworks betrachten und dann verschiedene Kriterien (Wie einfach ist
das Einarbeiten, welche Features für welchen Bereich sind vorhanden, ...)
auswerten. Sowas gibts ja auch häufig, aber hier bei den Frameworks habe
ich das leider nicht gefunden.
lg,
Martin
Marek Kubica
On Sat, 27 Jan 2007 15:23:20 +0000, Martin Schuette wrote:
> Kann ich als Admin eines Webservers das Benutzen von Python anbieten,
> dabei aber wie beim PHP safe-mode gewisse Sicherheitsrichtlinien
> (keine Shell, Zugriff nur auf's eigene Verzeichnis) gewährleisten?
> In der Doku zu mod_python habe ich dazu nichts gefunden.
Nein, soweit ich weiß nicht - in Falle PHPs funktioniert ist das schon
vergleichsweise unsicher - da wird's mit Python nicht besser aussehen. Um
so etwas richtig abzusichern (sowohl PHP als auch Python) nutzt du am
besten AppArmor oder SELinux.
grüße,
Marek
Marek Kubica
On Sat, 27 Jan 2007 20:11:16 +0100, Martin Kaffanke wrote:
> Naja, da gings vor allem um den Vergleich Schuhe Kaufen und Framework
> aussuchen.
Für Schuhe auswählen gibt es auch keinen Leitfaden. Du nimmst die Schuhe
die dir subjektiv passen. Ist sogar noch schwieriger, weil die Frameworks
sogar objektive Unterschiede haben (Performance, Dokumentation, Userbasis,
Anzahl der Zusatzlibs, etc.).
> Am liebsten wäre wir, wenn Expertenentscheidungen vorliegen, die
> objektiv die Frameworks betrachten und dann verschiedene Kriterien (Wie
> einfach ist das Einarbeiten, welche Features für welchen Bereich sind
> vorhanden, ...) auswerten. Sowas gibts ja auch häufig, aber hier bei
> den Frameworks habe ich das leider nicht gefunden.
Gibts doch. Guido findet Django gut. Stampfen wir den Rest ein ;)
Wen definierst du denn als Experten, so dass er dir diktieren kann welches
Framework dir am besten zu passen hat?
grüße,
Marek
Volker Grabsch
>> Die Unix-Klassiker, die zwar stdin und stdout umleiten, aber
>> dafür auch in C/C++ praktikabler als execvp+fork sind:
>>
>> os.popen2
>> os.popen3
>>
>> Oder spezielle Python-Funktionen, die es auch schon in 2.3 gibt:
>>
>> os.spawnv
>> os.spawnve
>> os.spawnvp
>> os.spawnvpe
>>
>> Die bauen allesamt Subprozesse auf und können allesamt die Argumente
>> einzeln bekommen.
>
> stdin/out/err muß ich aber immer noch manuell umleiten.
Ich verstehe nicht, was du mir damit sagen willst. Ich habe dir 2
Funktionen genannt, die i/o/err umleiten, und 4 Funktionen, die das
nicht tun.
> Und bei den
> popen-Funktionen gibt es AFAIR mindestens eine, die eben doch keine
> Parameterliste entgegennimmt. (Weiß nicht mehr, welche das war...
> os.popen, glaube ich)
Halbwissen. Was soll der Unsinn? Ich nehme mir die Zeit, meine Hinweise
schnell im Python-Interpreter auszuprobieren, und das selbe erwarte ich
von dir auch.
Außerdem habe das längst recherchiert, und es "popen", was du meinst,
und das ich aus eben diesem Grund oben *nicht* aufgeführt habe. Bist du
darauf aus, Verwirrung zu stiften? So kann man nicht miteinander umgehen.
>> Das hast du gesucht, oder?
>>
>> import os
>> os.spawnv(os.P_WAIT, "/bin/gzip", ["/bin/gzip", "--", infile])
>
> Wie würde ich damit gzip(str) implementieren zur Komprimierung der Daten
> im String str()? (Nein, temporäre Datei ist schlecht.)
Dafür nimmst du natürlich popen2. Für kleine Datenmengen (Strings) geht
doch folgendes super:
def gzip_compress(s):
tochild, fromchild = os.popen2(["/bin/gzip"])
tochild.write(s)
tochild.close()
return fromchild.read()
Große Datenmengen musst du natürlich aufteilen oder den "bufsize"-
Parameter von popen2 entsprechend hoch setzen, sonst gibt's ein
Deadlock. Bis auf das kann ich dein Problem beim besten Willen nicht
nachvollziehen.
Du kennst doch popen2 & Co, also warum argumentierst du gegen spawnv?
Was soll das?
> Wie gesagt, am saubersten ist es wohl, das mit os.fork, os.dup2 und eben
> doch os.exec* so nachzubilden, wie man es braucht.
Woher kriegst du dann deine Ein-/Ausgabeumleitung für das gzip?
> Was spricht denn konkret gegen ein Quoten aller Zeichen außer dem "'"
> durch Umschließen mit demselben und einem Quoten des "'" mit einem r"\"
> davor? (außer daß es Overhead ist, da ja 3 Ebenen untendrunter eben doch
> mit execv gearbeitet wird)
Das ist ein grundsätzliches Problem: Sauberes Quoten ist einfach ein
viel härteres Problem.
Selbst wenn du 20 Zeilen Code schreiben müsstest, um einen sauberen Weg
zu finden (in Wahrheit ist's nur eine), wäre dieser Aufwand noch
vertretbar. Du kannst deinen Code testen, und wenn er erstmal läuft, dann
weißt du, dass er auch sicher läuft. Dein Debugging/Testen beschränkt
sich also nur darauf, das Ding zum Laufen zu kriegen.
Beim Quoting hingegen kannst du ganz schnell ganz schlechten Code
schreiben, den du schnell zum Laufen kriegst. Aber sicheres Quoting,
das ist fast unmöglich. Es ist sehr aufwändig zu testen ... wie will
man das auch machen? Jede denkbare Zeichenkette durchprobieren?
Nein, Quoting kannst du nur dann sauber implementieren, wenn du einen
Standard zur Hand hast. Aber für die Shells gibt es keinen einheitlichen
Quoting-Standard. Das Hochkomma kann plötzlich doch noch irgendwas
"durchlassen". Du müsstest alle Schells austesten *und* all deren Dokus
lesen. bash, csh, tcsh, zsh, ...
Vielleicht ist sauberes Shell-Quoting möglich, aber ob das auf dein
eigenes gerade zutrifft, kannst du allein kaum feststellen.
Natürlich geht es nicht immer ohne Quoting. z.B. HTML/XML-Ausgabe
oder SQL-Befehle. Aber selbst hier geschieht das Quoting unter der
Haube. Die API verdeckt dieses Implementierungsdetailt sauber.
Kurz gesagt, was dagegen spricht: Shell-Quoting ist besonders hart *und*
es gibt API-Aufrufe, die kein Shell-Quoting benötigen. Jeder der beiden
Gründe allein wäre schon ausreichend, vom Shell-Quoting die Finger zu
lassen.
>>> Hinzu kommt: wenn man eine Funktion zur Ausfürung eines Prorgammes auf
>>> einem anderen Rechner via ssh schreiben will, kommt man um
>>> entsprechendes Quoting ebenfalls nicht herum,
>>
>> ACK. Diesen Probleme begegne ich persönlich aber lieber dadurch, dass
>> ich auf dem Zielrechner ein entsprechendes (Python- oder Shell-) Script
>> schreibe und dieses einfach aufrufe. Parameter kann ich dann über Stdin
>> übergeben, brauch ich aber meistens eh nicht.
>
> Wäre auch eine Möglichkeit, sicherlich. Kommt wohl auf den Einzelfall an.
> Wenn ich per stdin Nutzdaten übertragen will, wird das u.U. knifflig...
*Gerade* Nutzdaten lassen sich via stdin/stdout doch viel leichter
transportieren als über Shell-Argumente.
Christian Helmbold
De mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
noch andere Möglichkeiten außer Python, als Ersatz für PHP.
Christian Helmbold
Frank Pieper
> Ich habe die Kritik an PHP nach der Kritik an der Kritik überarbeitet.
> Da mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
> ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
> noch andere Möglichkeiten außer Python, als Ersatz für PHP.
Keine Ahnung was du für Schmerzen mit PHP durchleiten musstest, aber ich
kann nur sagen, deine Abhandlung ist eine von vielen und gäbe für mich
weder einen Grund dies zu verwenden, noch die Finger davon zu lassen.
Wenn Einsteiger das lesen werden die einfach verunsichert. Derartiges
findet sich vielfach zu jeder Sprache und wenn ich all diese Texte
früher gelesen und ernst genommen hätte, hätte ich villeicht nie
angefangen mich mit Programmierung zu beschäftigen. Wichtiger ist es,
die Vorteile eines Systems für bestimmte Aufgaben heraus zu stellen.
Besonderheiten wie C-Style Syntax und ähnliches sind geschmackssache. Da
kann auch jeman zu Python sagen, es sei Mist weil die Klammern fehlen
und deshalb wie VB sei. Muss mich selbst erstmal einarbeiten in Py und
werde keine Aussagen zu irgendwas machen nur mein lokales Wiki mit allen
Infos füttern, die ich für brauchbar halte.
Allgemein finde ich, es gibt für die unterschiedlichsten Aufgaben
unterschiedlichste Mittel. Auch PHP hat seine Berechtigung und ich muss
gestehen, ich mag es. Auch wenn manchen darin etwas unschön gelöst ist.
Während ich aber den ganzen Pear-Kram weglasse, lieben es andere. Wenn
schon derartige Halb-Offizielle Pakete wie Pear, dann bitte gleich in
C/C++ umgesetz, der Performance zu liebe.
Was interessiert mich, die Dokumentation des Quelltextes von Pythonm,
PHP oder sonst was. Ich will es Anwenden und nicht weiter entwickeln.
Entsprechend ist die verständliche Dokumentation der Befehle, APIs und
Bibliotheken wichtiger. Und zum besseren verständniss gleich in der
Muttersprache. Da hat PHP einen sehr grossen Vorteil gegenüber anderen
Sparachen. Z.B. finden sich zu C++ eine Menge Einsteigermaterial und
noch mehr Profihilfen. Aber irgendwie dazwischen ist eine grosses Loch.
In Python findet man einiges in Englisch aber nicht so viel in Deutsch.
PHP ist hier sehr angenehm. Wenn es dich wirklich interessiert, nehm den
Quellcode von PHP, nehm es auseinander und zerreisse ihn in einer
komplexen Detailierten Abhandlung. Glaube aber, da bist du mit deinen
Kenntnissen nicht wirklich weit genug.
Also wenn du etwas gegen die Verbreitung von PHP machen willst, setzt
dich eher direkt für Pyhton oder für Ruby ein. Das bringt mehr.
Und es gibt noch so viel andere feine Sachen wie AOP oder D wo einem
einfach die Zeit fehlt sich tiefer mit zu beschäftigen.
Diez B. Roggisch
> Ich habe die Kritik an PHP nach der Kritik an der Kritik überarbeitet.
> Da mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
> ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
> noch andere Möglichkeiten außer Python, als Ersatz für PHP.
Du solltest das lassen. Wer braucht sowas? PHP ist eine in vielen Aspekten
wirklich schlecht gestaltete Sprache, das ist unbestreitbar. Aber das
jemandem um die Ohren zu hauhen, der es verwendet - sei es weil er muss,
oder weil er nichts anderes kennt - hilft nichts. Sondern provoziert nur.
Ein tutorial, wie man mit wenigen Schritten zu einem beeindruckenden
Ergebnis durch Python kommt schon eher.
Diez
Ulf Kadner
> Ich habe die Kritik an PHP nach der Kritik an der Kritik überarbeitet.
> Da mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
> ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
> noch andere Möglichkeiten außer Python, als Ersatz für PHP.
Ich gehe mal auf die ersten Abschnitte ein.
| Die Schattenseite von PHP
Schon besser als vorher. Wennauch immernoch unpassend.
| Bei kleinen und mittleren Websites hat die Programmiersprache PHP
| weite Verbreitung gefunden.
Warum nur kleine und mittlere? Es gibt genügend größere Webseiten in PHP.
|Im Wesentlichen hat PHP zwei Vorteile:
|
| 1. Mit PHP kommt man sehr schnell zu einer dynamischen Website und
| 2. PHP ist weit verbreitet und bei jedem 0815/Provider installiert.
*zustimm*
| Die Gründer von Zend, Andi Gutmans und Zeev Suraski, hielten PHP/FI
| für zu schwach und entwickelten PHP 3 von Grund auf neu. PHP 3 war
| jedoch weder performant noch besonders sicher.
Alles korrekt. Aber heut zu Tage irrelevant. In näherer Zukunft kommt
schon PHP6.
| PHP 4 führte zu Verbesserungen bei Geschwindigkeit, Sicherheit und
| Portabilität. PHP 5 führte weitere Ergänzungen im Bereich der
| Objektorientierung ein.
Du solltest Dir mal das Changelog von PHP4 zu 5 ansehen! Das ist bei
weiten nicht alles. Aber für einen solchen Vergleich nicht wirklich von
interesse.
| Auch wenn es grundlegende Überarbeitungen gegeben hat, ist PHP doch
| organisch gewachsen.
Das tut jede Sprache...
| Das führt dazu, dass sehr viel ähnlicher Code an verschiedenen
| Stellen steht.
Da Du das ja so schön mit Python vergleichst. Du willst damit also
offerieren, das das in Python nicht so wäre? Das stimmt dann so sicher
nicht.
| Beispielhaft für das Flickwerk ist die Einstellung register_globals,
| mit der der Zugriff auf globale Variablen geregelt wird. Dieses
| Konstrukt war erforderlich, weil Angreifer sonst beliebige Variablen
| im Programm von außen beinflussen können.
Du verwechselst da was! register_globals wurde noetig weil es zu viele
PHP-Möchtegern-Programmierer gibt und gab, die nicht wirklich wissen was
sie gerad tun. Jeder sollte wissen, das eine Initialisierung einer
Variable im Script dieses Verhalten unterbindet. Da initialisierung auch
in anderen Sprachen keine Besonderheit darstellt ist das auch nix
ungewöhnliches.
| Ein anderes Beispiel ist die Übergabe von Objekten, die bis PHP 5
| als Wert (by value) und nicht als Referenz erfolgte.
Und? Das ist eine Eigenheit der Sprache und hat nix in Deiner Böseliste
verlohren!
| Neben Zend arbeiten jedoch zahlreiche weitere Entwickler an PHP. Das
| führt teilweise dazu, dass die Entwickler das tun, wozu sie gerade
| Lust haben und nicht was dringend nötig ist.
Sicher tut da keiner was unabgesprochenes. Wie kommst Du auf diese
Verwegene Aussage?
| Der Sicherheitsspezialist Stefan Esser hat das PHP-Projekt verlassen
| weil er es für aussichtslos hielt, PHP von innen sicherer zu machen.
Es gibt/gab immer Leute die etwas verlassen. Du offerierst damit:
"Böses PHP! Hat Sicherheitsexperten in den Wahnsinn getrieben.
Damit würde ich deshalb nicht programmieren."
| Nach eigener Darstellung wurde er angegriffen, weil er die Sicherheit
| von PHP kritisierte und viele seiner Vorschläge zur Verbesserung der
| Sicherheit seien abgelehnt worden.
Es gibt immer 2 Seiten an einer Medailie. Du kennst die Darstellung der
Gegenseite? Du kennst den Inhalt der abgelehnten Vorschläge? Du weist
wieso diese abgelehnt wurden? Ohne diese Informationen ist Deine Aussage
wertlos.
| Zahlreiche Sicherheitslücken listet heise online auf.
Davon hat auch jede andere Sprache ausreichend. Aber dazu braucht man
kein heise. Schau auf bugs.php.net
| Die geringen Ansprüche an die Qualität bei PHP treten auch in der
| Dokumentation des APIs auf.
Vollkommen unverständlich für mich. Sehr selten das ich mal was
undokumentiertes oder schlecht dokumentiertes gefunden habe.
| Das fängt schon damit an, dass die Funktionen nicht zu Themenbereichen
| (z.B. Datenbanken, Dateisystem...) zusammengefasst werden, sondern 182
| kleine kleine Funktionssammlungen in einer langen Liste stehen, die
| noch dazu römisch nummeriert ist, was kaum jemand flüssig lesen kann.
Und was ist daran etwas Nachteiliges? Woher willst Du wissen das andere
genauso empfinden wie Du? Ich finds übersichtlicher wie die meisten
anderen mir bekannten Sprachdokus.
| Diese Struktur ist übrigens nach Aussage von Projektmitgliedern
| deshalb zustande gekommen, weil das gewählte Dokumentationswerkzeug,
| nicht ausreichend viele Hierarchieebenen unterstützt.
Dazu kann ich nix sagen. Wo hast Du das her? Quelle bitte!
| Auf den einzelnen Übersichtsseiten der Funktionssammlungen erscheinen
| oft zunächst sehr lange Ausführungen, Voraussetzungen,
| Installationshinweise, Beispiele usw. bevor die eigentlichen
| Funktionen aufgelistet werden, die man aber am häufigsten braucht.
Halte ich ebenfalls für sehr sinnvoll. Aber selbst wenn ichs so wie Du
empfinden würde wäre das sicher nicht Bestandteil dieses Listings.
Das will keiner wissen. Über sowas kann man sich nunmal nur selbst ein
Bild machen.
| Die Dokumentation ist noch dazu lückenhaft, wie folgendes Beispiel
| zeigt:
| http://de.php.net/manual/de/function.imap-bodystruct.php
Kein Problem. Jeder Nutzer ist dazu aufgerufen fehlende Doks
nachzutragen. Mal abgesehen davon existieren nicht viele solcher
Fehlstellen.
| Die PHP-Dokumentation ist voll von unzureichenden Informationen.
So ein Unsinn! Es handelt sich lediglich um einige neu hinzugekommene
Elemente.
| Wem soll die folgende Auflistung von Konstanten ohne Erläuterung
| helfen?
| http://www.php.net/manual/de/ref.tidy.php
Jedem der etwas drüber nachdenken kann. Ich hatte auch bei Erstnutzung
von Tidy da keine Verständnisprobleme.
| "Version" ist das Stichwort für den nächsten Kritikpunkt: Es gibt nur
| eine Dokumentation für alle PHP-Versionen. Es ist zwar gekennzeichnet
| was in welcher Version dazugekommen ist, aber der Übersichtlichkeit
| ist das nicht dienlich.
mal was wo ich Dir zustimme.
Das koennte ich für Deinen gesamten Beitrag so weitermachen. Aber das
ist noch viel und mir fehlt die Zeit. Und auserdem wirds mit meiner
PHP-Gewichtung hier wohl zu sehr OT.
MfG, Ulf
Paul Ebermann
> | Bei kleinen und mittleren Websites hat die Programmiersprache PHP
> | weite Verbreitung gefunden.
>
> Warum nur kleine und mittlere? Es gibt genügend größere Webseiten in PHP.
Man denke etwa an die Wikipedias. Ganz am Anfang wurde da ein
leicht (und später stärker) modifiziertes Usemod-Wiki (Perl)
verwendet, aber irgendwann wurde das in PHP mit Datenbank
neuimplementiert (und heißt heute Mediawiki).
Ist aber eigentlich hier etwas Offtopic.
Paul
--
Nun ludigxas: : ()
Christian Helmbold
ich bin wirklich positiv von deiner Kritik überrascht!
> | Bei kleinen und mittleren Websites hat die Programmiersprache PHP
> | weite Verbreitung gefunden.
>
> Warum nur kleine und mittlere? Es gibt genügend größere Webseiten in PHP.
Das ist halt das, wo PHP besonders verbreitet ist (und sofern man PHP
eine Eignung unterstellen will, ist es das wofür es am geeignetsten
erscheint).
> | Die Gründer von Zend, Andi Gutmans und Zeev Suraski, hielten PHP/FI
> | für zu schwach und entwickelten PHP 3 von Grund auf neu. PHP 3 war
> | jedoch weder performant noch besonders sicher.
>
> Alles korrekt. Aber heut zu Tage irrelevant. In näherer Zukunft kommt
> schon PHP6.
Stimmt, die Geschichte ist für aktuelle Entscheidungen wirklich
unwichtig. Ich wollte damit nur zeigen, wie PHP zu dem geworden ist, was
es ist. Ich habe den ganzen Absatz gestrichen.
> | Auch wenn es grundlegende Überarbeitungen gegeben hat, ist PHP doch
> | organisch gewachsen.
>
> Das tut jede Sprache...
PHP wucherte jedoch auf unschöne Weise.
> | Das führt dazu, dass sehr viel ähnlicher Code an verschiedenen
> | Stellen steht.
>
> Da Du das ja so schön mit Python vergleichst. Du willst damit also
> offerieren, das das in Python nicht so wäre? Das stimmt dann so sicher
> nicht.
Beispielhaft ist doch die Funktionsauflistung mit den Sortierfunktionen.
Anstatt, dass sich mal einer richtig Gedanken macht, wie man das elegant
und vielseitig lösen könnte, wird hier und deine eine Funktion
dazugebastelt. Das ist API-Verschmutzung.
> | Ein anderes Beispiel ist die Übergabe von Objekten, die bis PHP 5
> | als Wert (by value) und nicht als Referenz erfolgte.
>
> Und? Das ist eine Eigenheit der Sprache und hat nix in Deiner Böseliste
> verlohren!
Das hat(te) da insofern was zu suchen, als die Weitsicht der Entwickler
nicht soweit reichte, dass diese Änderung vermieden werden konnte.
> | Der Sicherheitsspezialist Stefan Esser hat das PHP-Projekt verlassen
> | weil er es für aussichtslos hielt, PHP von innen sicherer zu machen.
>
> Es gibt/gab immer Leute die etwas verlassen. Du offerierst damit:
> "Böses PHP! Hat Sicherheitsexperten in den Wahnsinn getrieben.
> Damit würde ich deshalb nicht programmieren."
>
> | Nach eigener Darstellung wurde er angegriffen, weil er die Sicherheit
> | von PHP kritisierte und viele seiner Vorschläge zur Verbesserung der
> | Sicherheit seien abgelehnt worden.
>
> Es gibt immer 2 Seiten an einer Medailie. Du kennst die Darstellung der
> Gegenseite? Du kennst den Inhalt der abgelehnten Vorschläge? Du weist
> wieso diese abgelehnt wurden? Ohne diese Informationen ist Deine Aussage
> wertlos.
Ein bisschen habe ich schon davon mitbekommen, aber ich halte die
Sichtweise von Stefan Esser für realistischer. Ich erinnere mich an
einen Fehler, den sie in PHP für 32-Bit-Systeme behoben hatten, aber
nicht für 64-Bit-Systeme. Sowas spricht einfach nicht für den
Entwicklungsprozess.
> | Die geringen Ansprüche an die Qualität bei PHP treten auch in der
> | Dokumentation des APIs auf.
>
> Vollkommen unverständlich für mich. Sehr selten das ich mal was
> undokumentiertes oder schlecht dokumentiertes gefunden habe.
Als ich noch PHP benutzt habe, habe ich mich wirklich öfter über die
Doku geärgert. Es darf einfach nicht passieren, dass undokumentierte
Funktionen veröffentlicht werden!
> | Das fängt schon damit an, dass die Funktionen nicht zu Themenbereichen
> | (z.B. Datenbanken, Dateisystem...) zusammengefasst werden, sondern 182
> | kleine kleine Funktionssammlungen in einer langen Liste stehen, die
> | noch dazu römisch nummeriert ist, was kaum jemand flüssig lesen kann.
>
> Und was ist daran etwas Nachteiliges? Woher willst Du wissen das andere
> genauso empfinden wie Du? Ich finds übersichtlicher wie die meisten
> anderen mir bekannten Sprachdokus.
Ich finde es grausam! Aber die Aussage gibt ja auch meine Sicht wieder
und es steht jedem frei, das unkritisch zu sehen.
> | Diese Struktur ist übrigens nach Aussage von Projektmitgliedern
> | deshalb zustande gekommen, weil das gewählte Dokumentationswerkzeug,
> | nicht ausreichend viele Hierarchieebenen unterstützt.
>
> Dazu kann ich nix sagen. Wo hast Du das her? Quelle bitte!
Ich hatte vor ein paar Jahren darüber auf dem Newsserver der
PHP-Entwickler diskutiert. Leider gibt es den Server nicht mehr.
> | Auf den einzelnen Übersichtsseiten der Funktionssammlungen erscheinen
> | oft zunächst sehr lange Ausführungen, Voraussetzungen,
> | Installationshinweise, Beispiele usw. bevor die eigentlichen
> | Funktionen aufgelistet werden, die man aber am häufigsten braucht.
>
> Halte ich ebenfalls für sehr sinnvoll. Aber selbst wenn ichs so wie Du
> empfinden würde wäre das sicher nicht Bestandteil dieses Listings.
> Das will keiner wissen. Über sowas kann man sich nunmal nur selbst ein
> Bild machen.
Meine Auflistung gibt das wieder, was mich an PHP genervt hat.
Vielleicht sollte ich sie auch betiteln.
> | Die Dokumentation ist noch dazu lückenhaft, wie folgendes Beispiel
> | zeigt:
> | http://de.php.net/manual/de/function.imap-bodystruct.php
>
> Kein Problem. Jeder Nutzer ist dazu aufgerufen fehlende Doks
> nachzutragen.
Jeder Entwickler ist dazu aufgerufen, das Zeug, was er programmiert, zu
dokumentieren.
> | Wem soll die folgende Auflistung von Konstanten ohne Erläuterung
> | helfen?
> | http://www.php.net/manual/de/ref.tidy.php
>
> Jedem der etwas drüber nachdenken kann.
Ich empfinde sowas als Zumutung. Nur weil der Entwickler keinen Bock
hatte, einen kurzen Kommentar anzubringen, müssen unzählige Entwickler
rätseln, was sie damit machen sollen.
Christian Helmbold
> Du solltest das lassen. Wer braucht sowas?
Jemand der in Versuchung kommen könnte, PHP zu verwenden und jemand, der
in einem Projekt PHP verhindern will.
> PHP ist eine in vielen Aspekten
> wirklich schlecht gestaltete Sprache, das ist unbestreitbar. Aber das
> jemandem um die Ohren zu hauhen, der es verwendet - sei es weil er muss,
> oder weil er nichts anderes kennt - hilft nichts. Sondern provoziert nur.
Das ist ja wie gesagt auch nicht das Ziel. Wer masochistisch genug ist,
um mit PHP glücklich zu werden, der soll meinetwegen bei dieser Sprache
bleiben.
> Ein tutorial, wie man mit wenigen Schritten zu einem beeindruckenden
> Ergebnis durch Python kommt schon eher.
Ja, das ist die nächste Stufe, die in der Tat konstruktiver ist.
Martin Kaffanke
> Jemand der in Versuchung kommen könnte, PHP zu verwenden und jemand, der
> in einem Projekt PHP verhindern will.
> Das ist ja wie gesagt auch nicht das Ziel. Wer masochistisch genug ist,
> um mit PHP glücklich zu werden, der soll meinetwegen bei dieser Sprache
> bleiben.
Also ehrlich gesagt, nur weil du Probleme damit hast, PHP trotz seiner
Fehler zu verwenden, dann hast du noch viel größere Probleme, dass
jemand einen IE verwendet und solltest deine Webseiten generell gegen die
Benutzung von IE sperren, damit auch niemand eine Fehlerhafte Software bei
deinen Scripten verwenden kann. Ich denke, dass IE ein viel größeres
Problem ist als PHP. (Ich verwende PHP auch nur, wenn die Vorgaben sich
nicht soweit umbiegen lassen, dass ich doch irgendwie Python verwenden
kann, aber wenn es sein muss, schreibe ich auch PHP.)
>> Ein tutorial, wie man mit wenigen Schritten zu einem beeindruckenden
>> Ergebnis durch Python kommt schon eher.
>
> Ja, das ist die nächste Stufe, die in der Tat konstruktiver ist.
Ja, und oben drauf ein Tutorial wie man vom IE loskommt...
lg,
Martin
Thomas Rachel
>> Und bei den
>> popen-Funktionen gibt es AFAIR mindestens eine, die eben doch keine
>> Parameterliste entgegennimmt. (Weiß nicht mehr, welche das war...
>> os.popen, glaube ich)
>
> Halbwissen. Was soll der Unsinn? Ich nehme mir die Zeit, meine Hinweise
> schnell im Python-Interpreter auszuprobieren, und das selbe erwarte ich
> von dir auch.
Habe ich (leider erst nach dem Ansenden), um mein "glaube ich" zu bestätigen
- und sah danach keinen Korrekturbedarf mehr, da es ja stimmte. Andere
Handlungsreihenfolge wäre evtl. vorteilhaft gewesen...
> Außerdem habe das längst recherchiert, und es "popen", was du meinst,
> und das ich aus eben diesem Grund oben *nicht* aufgeführt habe. Bist du
> darauf aus, Verwirrung zu stiften? So kann man nicht miteinander umgehen.
Wie kommst Du auf "Verwirrung stiften"? Ok, vielleicht habe ich meine
Rahmenbedingungen etwas zu offen gelassen.
Wenn ich nun mal die Funktionalität von popen brauche, nämlich genau einen
der beiden ersten FDs umzubiegen, kann ich mit os.popen[23] nicht unbedingt
viel anfangen - es sei denn, ich kann/will/darf den/die "anderen" (bspw.
stdin) auf "leer" setzen bzw. schließen.
Nehmen wir mal als Beispiel ein Programm namens pipesum, dem als Parameter
die zu erzeugenden Prüfsummen mitgeteilt werden (aus der Menge sha1,
adler32, crc32, md4, md5, ed2k), und das dann auf stdout die entsprechenden
Prüfsummen des über stdin eingegebenen Datenstroms ausgibt.
Dann habe ich genau folgende Möglichkeiten:
- popen - und damit eben erforderliches Shellquoting,
- popen2 - und muß die Daten von Hand hineinschaufeln (sehr unperformant)
- selber was basteln mit os.fork, os.dup2, os.exec*, so daß ich einen FD auf
die geöffnete Datei übergeben kann (s.u.)
- oder eben das von Dir erwähnte subprocess.py (danke nochmal! - eigentlich
hat sich damit die Diskussion fast erübrigt, aber unten sind noch ein paar
offene Punkte, die ich noch gern klarstellen würde)
>> Wie gesagt, am saubersten ist es wohl, das mit os.fork, os.dup2 und eben
>> doch os.exec* so nachzubilden, wie man es braucht.
>
> Woher kriegst du dann deine Ein-/Ausgabeumleitung für das gzip?
ich habe noch os.pipe() vergessen. Abgesehen davon würde ich dann (!wenn es
subprocess nicht gäbe!) das in popen2.py verwendete Verfahren nachbilden:
- os.pipe() für die "eigene" Kommunikation dorthin bzw. os.open(), um die
Datei zu öffnen
- os.fork() für den Subprocess
im Child:
- os.dup2(), um den FD auf 0,1,2 zu legen, wie es das Programm erfordert
- os.exec*(), um das Programm zu starten
im Parent:
os.fdopen(), um ein File-Objekt zu bekommen
Aber diese Überlegung ist im Hinblick auf die Existenz von subprocess.py
relativ hinfällig, zumindest für lokalen Einsatz.
>> Was spricht denn konkret gegen ein Quoten aller Zeichen außer dem "'"
>> durch Umschließen mit demselben und einem Quoten des "'" mit einem r"\"
>> davor? (außer daß es Overhead ist, da ja 3 Ebenen untendrunter eben doch
>> mit execv gearbeitet wird)
>
> Das ist ein grundsätzliches Problem: Sauberes Quoten ist einfach ein
> viel härteres Problem.
Wenn man die genauen Regeln kennt, nicht unbedingt (s.u.).
> Selbst wenn du 20 Zeilen Code schreiben müsstest, um einen sauberen Weg
> zu finden (in Wahrheit ist's nur eine), wäre dieser Aufwand noch
> vertretbar. Du kannst deinen Code testen, und wenn er erstmal läuft, dann
> weißt du, dass er auch sicher läuft. Dein Debugging/Testen beschränkt
> sich also nur darauf, das Ding zum Laufen zu kriegen.
Soweit ACK.
> Beim Quoting hingegen kannst du ganz schnell ganz schlechten Code
> schreiben, den du schnell zum Laufen kriegst. Aber sicheres Quoting,
> das ist fast unmöglich. Es ist sehr aufwändig zu testen ... wie will
> man das auch machen? Jede denkbare Zeichenkette durchprobieren?
>
> Nein, Quoting kannst du nur dann sauber implementieren, wenn du einen
> Standard zur Hand hast. Aber für die Shells gibt es keinen einheitlichen
> Quoting-Standard.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_02_02
(The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition)
sagt ganz klar:
| Enclosing characters in single-quotes ( '' ) shall preserve the literal
| value of each character within the single-quotes. A single-quote cannot
| occur within single-quotes.
Klar kann es sein, daß eine Shell dagegen verstößt - aber das würde ich als
Bug ansehen, und gegen Bugs ist man nie gefeit. Und gegen etwas derart
grundlegendes zu verstoßen, wäre IMHO ein schwerer Bug. Und so gesehen
könnte exec* auch buggy sein im Hinblick auf gewisse Bytewerte, die so
selten als Parameter auftauchen, daß es einfach nicht auffällt.
> Kurz gesagt, was dagegen spricht: Shell-Quoting ist besonders hart *und*
> es gibt API-Aufrufe, die kein Shell-Quoting benötigen. Jeder der beiden
> Gründe allein wäre schon ausreichend, vom Shell-Quoting die Finger zu
> lassen.
Den zweiten Grund kann ich nachvollziehen. Den ersten nur mit
Einschränkungen. Daher werde ich zukünftig tendenziell eher mit
subprocess.py arbeiten, so es sich nicht vermeiden läßt. Diese
Einschränkung betrifft in erster Linie ssh.
[Remote-Aufruf per ssh]
>>> ACK. Diesen Probleme begegne ich persönlich aber lieber dadurch, dass
>>> ich auf dem Zielrechner ein entsprechendes (Python- oder Shell-) Script
>>> schreibe und dieses einfach aufrufe. Parameter kann ich dann über Stdin
>>> übergeben, brauch ich aber meistens eh nicht.
>>
>> Wäre auch eine Möglichkeit, sicherlich. Kommt wohl auf den Einzelfall an.
>> Wenn ich per stdin Nutzdaten übertragen will, wird das u.U. knifflig...
>
> *Gerade* Nutzdaten lassen sich via stdin/stdout doch viel leichter
> transportieren als über Shell-Argumente.
Ich meinte: Wenn man sowohl Parameter als auch Nutzdaten über stdin
übertragen will, wirds evtl. pfriemelig.
Mal angenommen, ich will ein Backup-Skript schreiben, welches seine Daten
auf einen Rechner A schreiben will und diesem mitteilen, er solle die
stdin-Daten in die per Parameter angegebene Datei schreiben.
Desweiteren möchte ich, um das Gesamtsystem einfacher warten zu können,
vermeiden, auf jedem der backupempfangenden Rechner ein Skript installieren
zu müssen.
Dann kann ich entweder:
1. <Backuperzeugung> |
ssh RechnerA 'cat >Dateiname' # diesen String und eben gescheit und
normgerecht (s.o.) quoten
oder
2. <Backuperzeugung> |
(printf "%s\0" Dateiname; cat) |
ssh Rechner A 'read -r -d "" dateiname && cat >$Dateiname'
Mir kommt erstere Lösung wesentlich sauberer vor, da die Ungewißheiten beim
Verhalten von read (speziell wenn man Nullbyteterminierung der Dateinamen
möchte, um wirklich alle Dateinamen verwenden zu können) IMHO größer sind
als die Ungewißheiten beim Quoten - das o.g. Zitat von OpenGroup kommt mir
recht eindeutig vor, zumal read auch eigentlich nur für Textdaten
spezifiziert ist und ich somit noch mehr auf die korrekte Implementierung
angewiesen bin als anderenfalls.
Ist in diesem Einsatz wohl im Endeffekt Geschmackssache; desweiteren scheint
mir das ein klein wenig vom Thema der Gruppe abzuweichen und eher nach
de.comp.os.unix.shell zu passen...
Thomas
--
In Kneipen nennt man Stammgäste Säufer, in Stadien Fans und im Usenet
Regulars. Ist ganz einfach. ;) (Torsten Gallus in dan-an)
Volker Grabsch
> [Remote-Aufruf per ssh]
>>>> ACK. Diesen Probleme begegne ich persönlich aber lieber dadurch, dass
>>>> ich auf dem Zielrechner ein entsprechendes (Python- oder Shell-) Script
>>>> schreibe und dieses einfach aufrufe. Parameter kann ich dann über Stdin
>>>> übergeben, brauch ich aber meistens eh nicht.
>>>
>>> Wäre auch eine Möglichkeit, sicherlich. Kommt wohl auf den Einzelfall an.
>>> Wenn ich per stdin Nutzdaten übertragen will, wird das u.U. knifflig...
>>
>> *Gerade* Nutzdaten lassen sich via stdin/stdout doch viel leichter
>> transportieren als über Shell-Argumente.
>
> Ich meinte: Wenn man sowohl Parameter als auch Nutzdaten über stdin
> übertragen will, wirds evtl. pfriemelig.
>
> Mal angenommen, ich will ein Backup-Skript schreiben, welches seine Daten
> auf einen Rechner A schreiben will und diesem mitteilen, er solle die
> stdin-Daten in die per Parameter angegebene Datei schreiben.
Das ist ein sehr schlechtes Beispiel. Gerade *das* will man nicht
selbst bauen.
> Dann kann ich entweder:
>
> 1. <Backuperzeugung> |
> ssh RechnerA 'cat >Dateiname' # diesen String und eben gescheit und
> normgerecht (s.o.) quoten
>
> oder
>
> 2. <Backuperzeugung> |
> (printf "%s\0" Dateiname; cat) |
> ssh Rechner A 'read -r -d "" dateiname && cat >$Dateiname'
>
> Mir kommt erstere Lösung wesentlich sauberer vor,
Lösung 2 ist sinnvoller, nur dass du das Protokoll nicht selbst
definieren solltest, sondern z.B. einen Tar-Datenstrom sendest.
Der Empfänger führt einfach ein "tar -x" aus, fertig.
Oder du nimmst gleich SCP bzw. SFTP, so wie es jeder normale
Admin tut.
Oder du nimmst RSync, so wie es jeder erfahrene Admin tut. Das
überträgt nur die Differenzen, kann daher auch abgebrochene Uploads
weiterführen, ... kurz: RSync ist wie Geschaffen für's Backup.
Halt, moment! RSync *ist* Geschaffen für's Backup. ;-)
> da die Ungewißheiten beim
> Verhalten von read (speziell wenn man Nullbyteterminierung der Dateinamen
> möchte, um wirklich alle Dateinamen verwenden zu können) IMHO größer sind
> als die Ungewißheiten beim Quoten
Beide Formen der Ungewissheit sind nicht tolerierbar, deshalb nimmt man
ein Archiv-Dateiformat (ZIP, Tar, ...) oder ein fertiges Datei-Transfer-
Protokoll (FTP, SCP, SFTP, RSync).
> Ist in diesem Einsatz wohl im Endeffekt Geschmackssache; desweiteren scheint
> mir das ein klein wenig vom Thema der Gruppe abzuweichen und eher nach
> de.comp.os.unix.shell zu passen...
Allerdings.
X-Post und F'up nachgeholt.
Mathias Panzenboeck
> Christian Helmbold <c.hel...@gmx.de> wrote:
>> ich habe mir mal den Spaß gemacht und in Worte gefasst, wie schlecht PHP
>> ist. Teilweise habe ich einen Vergleich zu Python angestellt, weil man
>
>
Hmm, Visual Basic?
>
> PHP hatte anfangs ja den angeblichen Vorteil mit HTML-Code
> gemischt zu sein. Heutzutage sagen sogar die PHP-"Profis" man
> solle ein Template benutzen.
>
Auch in dem Punkt heb es sich net ab. Das geht bei anderen Sprachen genauso. Sogar mit Python.
> Also hebt sich PHP in dieser Hinsicht von keiner anderen Sprache
> ab. Es gibt praktisch keine lebende Programmiersprache, für die
> es keine Webanbindung gibt.
>
Ja. Von C bis Haskell gibts alles! Schon ne kranke Welt. ;)
Naja, Assembler fehlt noch. *g*
>
> "Sollen wir für das Projekt PHP nehmen, oder ..." - "ODER!!"
>
>
Auch wenn das "oder" Visual Basic ist? (Vor .NET)
Mathias Panzenboeck
>
> Prozedural/Strukturiert:
> Kontrast zu Goto-Spaghetti-Code
>
> Objektorientiert:
> Funktionen und ihre Datenstrukturen sollen zusammenbleiben,
> Polymorphie.
> Kontrast zu strukturiertem Spaghetti-Code, der vor Switch-Anweisungen
> strotzt.
>
> Funktional:
> Kontrast zu Code, in dem zu viele Seiteneffekte für Verwirrung
> und Bugs sorgen.
>
Wir haben's auf der Uni so strukturiert gelernt:
Imperative Sprachen:
*) Prodezurale Sprachen: ASM, C, Basic, sh, ...
*) Objektorienteirte Sprachen: C++, D, Java, C#, Python, Ruby, ...
Deklarative Sprachen:
*) Funktionale Sprachen: Haskell, Lisp, ...
*) Logikorientierte Sprachen: Prolog, DLV, ...
Es gibt auch Mischungen (OCAML etc.), und wie gesagt hat auch Python ein paar (nicht alle) der
Eigenschaften, die eine Funktionale Sprache ausmachen: lambda-Ausdrücke, list-comprehension,
Funktionen sind first class citizen (aber eigentlich sind das Funktionen in C ja auch) und
Funktionen höherer Ordnung. Und mit Generatoren hat Python auch etwas lazy-artiges. :)
Aber es gibt genügend weitere Paradigmen wie z.B. "dynamische" Sprachen (Python, Ruby, JavaScript)
Vs. "statische" Sprachen (C, C++, Java, C#, ...), Skriptsprachen Vs. geJITete Sprachen Vs. native
Sprachen, "typesafe" Vs. "not typesafe" etc.
-panzi
Mathias Panzenboeck
> Ich habe die Kritik an PHP nach der Kritik an der Kritik überarbeitet.
> Da mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
> ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
> noch andere Möglichkeiten außer Python, als Ersatz für PHP.
>
> Gruß
> Christian
>
ereg() ist nicht binär-sicher.
Was heißt das? Was ist ereg()?
-panzi
Mathias Panzenboeck
> Ich habe die Kritik an PHP nach der Kritik an der Kritik überarbeitet.
> Da mein Ziel war, zu zeigen, wie schlecht PHP und nicht wie gut Python
> ist, habe ich den Teil zu Python stark verkürzt. Außerdem erwähne ich
> noch andere Möglichkeiten außer Python, als Ersatz für PHP.
>
> Gruß
> Christian
>
Auch noch zu dem Thema: Nerds on Air - Radio for Geeks: Web (In-)Security
http://www.clifford.at/noa/noa_2007_02_02_websec.mp3
Geht viel um PHP.
Weitere Sendungen:
http://www.clifford.at/noa/
Volker Grabsch
<OT>
überprüf mal bitte deine Zeilenlängen. 75 ist ein guter Wert, nicht 95.
Das erhöht gerade bei Fließtext die Lesbarkeit ungemein. Bei langen
Texten ist sogar eine Zeilenlänge von 60 Zeichen zum empfehlen.
</OT>
Mathias Panzenboeck <e042...@student.tuwien.ac.at> schrieb:
> Es gibt auch Mischungen (OCAML etc.), und wie gesagt hat auch Python
> ein paar (nicht alle) der Eigenschaften, die eine Funktionale Sprache
> ausmachen: lambda-Ausdrücke,
Die lambda-Ausdrück in Python sind sehr kastriert. Was den klassichen
Lambda-Ausdrücken in Python am ähnlichsten kommt, sind Unterfunktionen,
d.h. wenn man so will, muss man jedem anspruchsvollen Lambda-Ausdruck
in Python einen Namen geben.
> Funktionen sind first class citizen (aber eigentlich sind das Funktionen
> in C ja auch)
Das ist falsch!
In C/C++ kannst du keine Funktionen als Rückgabewerte haben. Jedenfalls
keine, die erst innerhalb einer anderen Funktion definiert werden.
Das fehlende Konzept von Closures macht C sogar so schwach, dass es
nichtmal eine gute Ocaml -> C Übersetzung gibt. Der Stack etc. muss
selbst verwaltet werden, dazu braucht man direkten Assembler, weil
das in C nur umständlich nachgebaut werden könnte.
Eigentlich schade, aber so ist das nunmal. C und C++ sind in diesem
Punkt einfach zu schwach bestückt.
> Und mit Generatoren hat Python auch etwas lazy-artiges. :)
Das hat es schon durch Lambdas. PEAK macht das beispielsweise.
Stargaming
[snip]
>> ereg() ist nicht binär-sicher.
>
> Was heißt das? Was ist ereg()?
Ich vermute http://de.php.net/ereg.
Mathias Panzenboeck
> Hallo Mathias,
>
> <OT>
> überprüf mal bitte deine Zeilenlängen. 75 ist ein guter Wert, nicht 95.
> Das erhöht gerade bei Fließtext die Lesbarkeit ungemein. Bei langen
> Texten ist sogar eine Zeilenlänge von 60 Zeichen zum empfehlen.
> </OT>
>
Also ich bin ja der Meinung das im 21. Jarhundert 75 Zeichen pro
Zeile ein wenig wenig sind. Wo liegt das Problem? Bei einer Auflösung
von 1280x1024 sind 95 Zeichen eigentlich immer noch eine
Platzverschwendung.
>
> Mathias Panzenboeck <e042...@student.tuwien.ac.at> schrieb:
>> Es gibt auch Mischungen (OCAML etc.), und wie gesagt hat auch Python
>> ein paar (nicht alle) der Eigenschaften, die eine Funktionale Sprache
>> ausmachen: lambda-Ausdrücke,
>
> Die lambda-Ausdrück in Python sind sehr kastriert. Was den klassichen
> Lambda-Ausdrücken in Python am ähnlichsten kommt, sind Unterfunktionen,
> d.h. wenn man so will, muss man jedem anspruchsvollen Lambda-Ausdruck
> in Python einen Namen geben.
>
>> Funktionen sind first class citizen (aber eigentlich sind das Funktionen
>> in C ja auch)
>
> Das ist falsch!
>
> In C/C++ kannst du keine Funktionen als Rückgabewerte haben.
Natürlich geht das. Function-Pointers!
> Jedenfalls
> keine, die erst innerhalb einer anderen Funktion definiert werden.
Ja das nicht, aber davon war ja nicht die Rede.
> Das fehlende Konzept von Closures macht C sogar so schwach, dass es
> nichtmal eine gute Ocaml -> C Übersetzung gibt. Der Stack etc. muss
> selbst verwaltet werden, dazu braucht man direkten Assembler, weil
> das in C nur umständlich nachgebaut werden könnte.
>
> Eigentlich schade, aber so ist das nunmal. C und C++ sind in diesem
> Punkt einfach zu schwach bestückt.
>
>> Und mit Generatoren hat Python auch etwas lazy-artiges. :)
>
> Das hat es schon durch Lambdas. PEAK macht das beispielsweise.
>
>
> Viele Grüße,
>
> Volker
>
MfG,
panzi
Mathias Panzenboeck
Ja, aber was heißt das "nicht binär-sicher"?
Marc 'BlackJack' Rintsch
wrote:
> Also ich bin ja der Meinung das im 21. Jarhundert 75 Zeichen pro
> Zeile ein wenig wenig sind. Wo liegt das Problem? Bei einer Auflösung
> von 1280x1024 sind 95 Zeichen eigentlich immer noch eine
> Platzverschwendung.
Das hat weder etwas mit dem Jahrhundert noch mit der Auflösung zu tun,
dass zu lange Zeilen schwerer zu lesen sind. Und im 21. Jahrhundert gibt
es auch Leute, die News auf viel kleineren Displays lesen, zum Beispiel
auf PDAs oder Smartphones.
Ciao,
Marc 'BlackJack' Rintsch
Bjoern Schliessmann
> Ja, aber was heißt das "nicht binär-sicher"?
Vielleicht, dass die Funktion mit binärem Zeug in Strings nicht
zurechtkommt?
BTW: http://www.heise.de/security/news/meldung/74319
Grüße,
Björn
--
BOFH excuse #366:
ATM cell has no roaming feature turned on, notebooks can't connect
Marc 'BlackJack' Rintsch
wrote:
> Es gibt auch Mischungen (OCAML etc.), und wie gesagt hat auch Python ein
> paar (nicht alle) der Eigenschaften, die eine Funktionale Sprache
> ausmachen: lambda-Ausdrücke, list-comprehension, Funktionen sind first
> class citizen (aber eigentlich sind das Funktionen in C ja auch) und
> Funktionen höherer Ordnung. Und mit Generatoren hat Python auch etwas
> lazy-artiges. :)
Welche Eigenschaften fehlen denn Python zu einer funktionalen Sprache?
Haupteigenschaft sind doch wohl Funktionen höherer Ordnung. Anonyme
Funktionen, List-Comprehensions und Lazy-Evaluation sind optional.
Ciao,
Marc 'BlackJack' Rintsch
Bjoern Schliessmann
> Also ich bin ja der Meinung das im 21. Jarhundert 75 Zeichen pro
> Zeile ein wenig wenig sind. Wo liegt das Problem? Bei einer
> Auflösung von 1280x1024 sind 95 Zeichen eigentlich immer noch eine
> Platzverschwendung.
Hast du dir schonmal Gedanken gemacht, wieso ein Zeitungsartikel nie
die volle Seitenbreite ausnutzt und oft sogar mehrspaltig gesetzt
ist?
Leicht verwunderte Grüße,
Björn
--
BOFH excuse #269:
Melting hard drives
Mathias Panzenboeck
ähm. ich lese keine Zeitung, sondern nur news feeds. :)
Mathias Panzenboeck
deklarativität. also statt prozedural eins nach dem andern alles per rekursionen und deklerationen
etc. gelößt. und ich glaub i.d.R. sind in einer funktionalen sprache objekte immutable.
und "funktionsüberladung" auf die art: [] = "nothing"
foo (x:(y:z)) = "more then two"
foo (x:y) = "more then one"
aber so 100%ig weiß ich auch net was da noch fehlt, denn so große punkte sind das eigentlich auch
net. es gibt ja stackless python und das mit der funktionsüberladung kann man zur not mit
if-elif-else nachbaun.
Diez B. Roggisch
> deklarativität. also statt prozedural eins nach dem andern alles per rekursionen und deklerationen
> etc. gelößt. und ich glaub i.d.R. sind in einer funktionalen sprache objekte immutable.
> und "funktionsüberladung" auf die art: [] = "nothing"
> foo (x:(y:z)) = "more then two"
> foo (x:y) = "more then one"
Das heisst nicht ueberladung, sonder pattern matching und ist etwas
voellig anderes, da es auf konkrete Werte matcht und nicht auf
verschieden Typen.
> aber so 100%ig weiß ich auch net was da noch fehlt, denn so große punkte sind das eigentlich auch
> net. es gibt ja stackless python und das mit der funktionsüberladung kann man zur not mit
> if-elif-else nachbaun.
Stackless hat damit ueberhaupt nichts zu tun - das was du meinst ist
tail recursion elimination, und die entkopplung vom C-stack in stackless
hat damit nichts zu tun. Es gibt aber zB exception-basierte
tail-recursion dekoratoren auch fuer standard-python.
Diez
Marc 'BlackJack' Rintsch
wrote:
> Marc 'BlackJack' Rintsch schrieb:
>> In <45f04c04$0$28520$3b21...@tunews.univie.ac.at>, Mathias Panzenboeck
>> wrote:
>>
>>> Es gibt auch Mischungen (OCAML etc.), und wie gesagt hat auch Python ein
>>> paar (nicht alle) der Eigenschaften, die eine Funktionale Sprache
>>> ausmachen: lambda-Ausdrücke, list-comprehension, Funktionen sind first
>>> class citizen (aber eigentlich sind das Funktionen in C ja auch) und
>>> Funktionen höherer Ordnung. Und mit Generatoren hat Python auch etwas
>>> lazy-artiges. :)
>>
>> Welche Eigenschaften fehlen denn Python zu einer funktionalen Sprache?
>> Haupteigenschaft sind doch wohl Funktionen höherer Ordnung. Anonyme
>> Funktionen, List-Comprehensions und Lazy-Evaluation sind optional.
>
> deklarativität. also statt prozedural eins nach dem andern alles per
> rekursionen und deklerationen etc. gelößt.
Das kannst Du in Python auch machen wenn Du möchtest. Wenn Du den
prozeduralen Stil ganz verbieten möchtest, dann sind auch Lisp, Scheme,
Nemerle und OCaml keine funktionalen Programmiersprachen. Dem würden
aber sicher viele Programmierer widersprechen. ;-)
Und so wirklich rein funktional fällt mir nur Haskell ein.
> und ich glaub i.d.R. sind in einer funktionalen sprache objekte
> immutable. und "funktionsüberladung" auf die art: [] = "nothing" foo
> (x:(y:z)) = "more then two"
> foo (x:y) = "more then one"
"Pattern matching" ist optional. Lisp und Scheme bieten das so weit ich
weiss auch nicht von Haus aus. Allerdings gibt's natürlich Erweiterungen
dafür. Sollte mit Dekoratoren in Python auch bis zu einem gewissen Grad
machbar sein. Ist ja so ähnlich wie "multi methods" und dafür gibt es
Implementierungen.
Das grösste Manko bei CPython ist die fehlende "tail call optimization",
aber das ist ein Implementierungsdetail und keine Eigenschaft der Sprache.
Ciao,
Marc 'BlackJack' Rintsch
Volker Grabsch
> In <45f1e88d$0$11868$3b21...@tunews.univie.ac.at>, Mathias Panzenboeck
> wrote:
>
>> Also ich bin ja der Meinung das im 21. Jarhundert 75 Zeichen pro
>> Zeile ein wenig wenig sind. Wo liegt das Problem? Bei einer Auflösung
>> von 1280x1024 sind 95 Zeichen eigentlich immer noch eine
>> Platzverschwendung.
>
> Das hat weder etwas mit dem Jahrhundert noch mit der Auflösung zu tun,
> dass zu lange Zeilen schwerer zu lesen sind.
Ja, darum geht es mir.
Außerdem ist es *gerade* bei großen Monitoren nicht mehr nötig, das Sichtfeld
voll auszumalen. Lieber zwei oder drei Textfenster nebeneinander.
Zugegeben, im Quelltext gehe ich auch gern mal über 80 Zeichen, aber nur
dann, wenn's wirklich der Übersichtlichkeit dient. Für Fließtext gilt
das nicht.
Schau dir mal Webseiten/Webdesign an: Du findest keine Seite, die
elendig breite Textbereiche hat. Bei ner Zeitung ist das was anderes,
da darf man kein Papier verschwenden, das wird teuer. Am Bildschirm ist
ungenutzter Platz kein Argument, wenn man ihn nicht braucht. Und wenn man
ihn braucht (man will mehrere Programme gleichzeitig bedienen), dann ist
das erst recht ein Argument dafür, die einzelnen Fenster nicht zu breit zu
ziehen.
Und selbst bei ner Zeitung sind die Texte in mehreren dünnen Spalten
untergebraucht, warum wohl? Lesbarkeit!
Beim Lesen springt das Auge wie eine Schreibmaschine am Ende einer Zeile
zum Anfang der nächsten. Sind die Zeilen zu lang, verfehlt es häufiger
die nächste Zeile. Bücherwürmen kennen dieses Phänomen sicherlich. Das
andere Extrem ist genauso schlecht: Sind die Zeilen zu kurz (z.B. ein
Worte pro Zeile), dann muss das Auge ständig springen, was ebenfalls
sehr unangenehm ist.
Ungefähr 60-70 Zeichen (bzw. 6-8 Worte) pro Zeile sind AFAIK das
Optimum an Lesbarkeit.
Manchmal stelle ich bei einer Webseite im Browser die Schriftgröße
extra hoch. Nicht, weil mir die Buchstaben zu klein sind, sondern
das Lesen der elendig langen Zeilen nervt!
> Und im 21. Jahrhundert gibt
> es auch Leute, die News auf viel kleineren Displays lesen, zum Beispiel
> auf PDAs oder Smartphones.
Das ist ebenfalls ein Argument, aber IMHO ein viel schwächeres.
Bjoern Schliessmann
> Außerdem ist es *gerade* bei großen Monitoren nicht mehr nötig,
> das Sichtfeld voll auszumalen. Lieber zwei oder drei Textfenster
> nebeneinander.
>
> Zugegeben, im Quelltext gehe ich auch gern mal über 80 Zeichen,
> aber nur dann, wenn's wirklich der Übersichtlichkeit dient. Für
> Fließtext gilt das nicht.
ACK.
> Schau dir mal Webseiten/Webdesign an: Du findest keine Seite, die
> elendig breite Textbereiche hat.
Falsch, man findet tausende ;) Die guten haben aber lesbare
Zeilenlängen.
> Beim Lesen springt das Auge wie eine Schreibmaschine am Ende einer
> Zeile zum Anfang der nächsten. Sind die Zeilen zu lang, verfehlt
> es häufiger die nächste Zeile. Bücherwürmen kennen dieses Phänomen
> sicherlich. Das andere Extrem ist genauso schlecht: Sind die
> Zeilen zu kurz (z.B. ein Worte pro Zeile), dann muss das Auge
> ständig springen, was ebenfalls sehr unangenehm ist.
Das Auge muss sowieso ständig springen, kontinuierlich abtasten ist
nicht.
> Ungefähr 60-70 Zeichen (bzw. 6-8 Worte) pro Zeile sind AFAIK das
> Optimum an Lesbarkeit.
Nicht unbedingt. Kürzere Zeilen (wie in Zeitungen) erlauben sogar,
wenn man geübt ist, fast vertikal zu lesen.
Grüße,
Björn
--
BOFH excuse #364:
Sand fleas eating the Internet cables
Florian Diesch
> Volker Grabsch schrieb:
>> Hallo Mathias,
>>
>> <OT>
>> überprüf mal bitte deine Zeilenlängen. 75 ist ein guter Wert, nicht 95.
>> Das erhöht gerade bei Fließtext die Lesbarkeit ungemein. Bei langen
>> Texten ist sogar eine Zeilenlänge von 60 Zeichen zum empfehlen.
>> </OT>
>>
>
> Also ich bin ja der Meinung das im 21. Jarhundert 75 Zeichen pro
> Zeile ein wenig wenig sind. Wo liegt das Problem? Bei einer Auflösung
> von 1280x1024 sind 95 Zeichen eigentlich immer noch eine
> Platzverschwendung.
Für die Lesbarkeit sind - unabhängig vom Medium - 60-80 Zeichen/Zeile
optimal.
Den Platz auf dem Bildschirm kann man ja mit anderen Fenstern füllen.
Florian
--
<http://www.florian-diesch.de/>
Mathias Panzenboeck
>>
>> deklarativität. also statt prozedural eins nach dem andern alles per
>> rekursionen und deklerationen
>> etc. gelößt. und ich glaub i.d.R. sind in einer funktionalen sprache
>> objekte immutable.
>> und "funktionsüberladung" auf die art: [] = "nothing"
>> foo (x:(y:z)) = "more then two"
>> foo (x:y) = "more then one"
>
> Das heisst nicht ueberladung, sonder pattern matching und ist etwas
> voellig anderes, da es auf konkrete Werte matcht und nicht auf
> verschieden Typen.
>
Ja mit Bezeichnungen hab ich immer Probleme. Kann mir nie merken wie
was heißt. Ich verstehs zwar, kann damit umgehn, aber wie's heißt, kA.
>> aber so 100%ig weiß ich auch net was da noch fehlt, denn so große
>> punkte sind das eigentlich auch
>> net. es gibt ja stackless python und das mit der funktionsüberladung
>> kann man zur not mit
>> if-elif-else nachbaun.
>
> Stackless hat damit ueberhaupt nichts zu tun - das was du meinst ist
> tail recursion elimination, und die entkopplung vom C-stack in stackless
> hat damit nichts zu tun. Es gibt aber zB exception-basierte
> tail-recursion dekoratoren auch fuer standard-python.
>
ic
> Diez
Mathias Panzenboeck
> Mathias Panzenboeck wrote:
>
>> Ja, aber was heißt das "nicht binär-sicher"?
>
> Vielleicht, dass die Funktion mit binärem Zeug in Strings nicht
> zurechtkommt?
>
> BTW: http://www.heise.de/security/news/meldung/74319
>
ic
Volker Grabsch
Was möchte uns der Autor damit sagen? ;-)
Bjoern Schliessmann
> Was möchte uns der Autor damit sagen? ;-)
Naiv-englische Abkürzung für "ach so".
Grüße,
Björn
--
BOFH excuse #301:
appears to be a Slow/Narrow SCSI-0 Interface problem
Volker Grabsch
> Volker Grabsch wrote:
>
>> Was möchte uns der Autor damit sagen? ;-)
>
> Naiv-englische Abkürzung für "ach so".
IC
In der Schreibweise "ic" sah's aber eher aus wie ein angefangener
Text ("ich ..."), der irgendwie durch Fehlbedienung des Newsclient
abgebrochen gepostet wurde. ;-)