Hallo,

hat jemand Erfahrung mit der Kombination Python - PHP? Und zwar so, dass
aus PHP in einem system()-call Python aufgerufen wird. Die
Anwendungslogik würde dabei objektorientiert in Python implementiert
werden, während PHP für die Ausgabe zuständig ist.

Vorteile aus meiner Sicht:
- jede Sprache macht das, wofür sie entworfen wurde bzw. am besten
geeignet ist
- Geschwindigkeitsvorteil durch vorkompilierten Python-Code

Nachteile:
- zwei Interpreter pro Request

Wie ist Eure Meinung dazu?

Vielen Dank im voraus
Christian


--
WWW: http://www.netzologie.de
WWW: http://www.htmlfee.de
Mail: vorname.nachname (bei) gmx.net

Christian Smietana schrieb:
> Hallo,
>
> hat jemand Erfahrung mit der Kombination Python - PHP? Und zwar so, dass
> aus PHP in einem system()-call Python aufgerufen wird. Die
> Anwendungslogik würde dabei objektorientiert in Python implementiert
> werden, während PHP für die Ausgabe zuständig ist.
>
> Vorteile aus meiner Sicht:
> - jede Sprache macht das, wofür sie entworfen wurde bzw. am besten
> geeignet ist
> - Geschwindigkeitsvorteil durch vorkompilierten Python-Code

> Nachteile:
> - zwei Interpreter pro Request


Als generelles Muster - zu kompliziert & unhandlich. Besser per XMLRPC
aus PHP einen laufenden Python-Prozess ansprechen.

Oder gleich auf PHP verzichten. Das meine ich ernst. Es ist nicht
wirklich gut. Seine Vorteile sind die allgemeine Verfuegbarkeit &
geringe Einstiegshuerde. Aber wenn du _eh_ schon Python kannst, dann
nimm ein Webframework, zB TurboGears, Pylons oder Django.

Diez

Diez B. Roggisch wrote:

> Oder gleich auf PHP verzichten. Das meine ich ernst. Es ist nicht
> wirklich gut.

Das in einer php-Newsgroup zu äußern, dazu gehört schon Mut. ;-)

> Seine Vorteile sind die allgemeine Verfuegbarkeit & geringe Einstiegshu=
erde.

Umgekehrt wird ein Schuh draus. Das Märchen von der geringen
Einstiegshürde führt zu dem Fehlschluß, PHP sei nicht gut, denn daß=
so
viele Anfänger das Märchen glauben und sich von den vielen "alles gan=
z
einfach" Tutorials verführen lassen, anstatt die Sprache vernünftig z=
u
lernen, führt zu den allermeisten Problemen, die allesamt vor dem
Bildschirm sitzen. Wenn man PHP gleich richtig lernt, ist es nicht
leichter zu erlernen, als andere Scriptsprachen, und m. E. auch nicht
schlechter.

Alex

F'up2 de.comp.lang.php.misc

Christian Smietana schrieb:
> Die Anwendungslogik würde dabei objektorientiert in Python
> implementiert werden, während PHP für die Ausgabe zuständig ist.

Hallo Christian!

Entweder PHP oder Python. Ich sehe keinen Vorteil darin, Python mit PHP
zu verknüpfen. Wenn du gut mit PHP klar kommst, dann mach alles mit PHP,
und wenn du mit Python gut klar kommst, dann mach alles mit Python.

Immer diese Vorurteile, dass Python nur für die Anwendungslogik gut sein
soll... :-(

Der Vorteil den PHP bieten kann ist: es lässt sich sehr leicht in den
Apachen integrieren. Man kann einen Server für "viele" einrichten, ohne
jedem Webspace-Kunden irgendwelche Ausführberechtigungen geben zu
müssen. Das Leben eines Providers ist mit PHP heutzutage viel einfacher
als mit Python.

Sobald du SSH-Zugang zu einem Server hast oder du sogar einen (V-)Server
angemietet hast, dreht sich die Lage komplett um. Ich kenne keinen
Python-Programmierer, der freiwillig wieder etwas mit PHP machen würde.
Es gibt einige wirklich gute Python-Webframeworks und Helferlein wie
z.B. CherryPy, Cheetah, Werkzeug oder Django, die einen das Leben mit
PHP schnell vergessen lassen. (Und mir ist das jetzt egal, wenn das auch
in de.comp.lang.php.misc gelesen wird.)

mfg
Gerold
:-)

--
____________________________________________________________ ____________
Gerold Penz - bcom - Programmierung
http://gerold.bcom.at | http://sw3.at
Wissen hat eine wunderbare Eigenschaft:
Es verdoppelt sich, wenn man es teilt.

> Sobald du SSH-Zugang zu einem Server hast oder du sogar einen (V-)Server
> angemietet hast, dreht sich die Lage komplett um. Ich kenne keinen
> Python-Programmierer, der freiwillig wieder etwas mit PHP machen würde.
> Es gibt einige wirklich gute Python-Webframeworks und Helferlein wie
> z.B. CherryPy, Cheetah, Werkzeug oder Django, die einen das Leben mit
> PHP schnell vergessen lassen. (Und mir ist das jetzt egal, wenn das auch
> in de.comp.lang.php.misc gelesen wird.)

In der Aufzählung der Frameworks liegt doch genau das Problem begründet:
Du vergleichst Sprache mit Sprache+Framework, da dieses bei Python fast
schon zwingend zu sein scheint (es sei denn, man legt Wert darauf, alles
selber zu machen). Dann müsste ich als potentiell Migrationswilliger
erst mal wissen, welches Framework, und dürfte dann erst mal dieses
lernen. Und nach allem, was ich gesehen habe, ist die Grösse eines
Projekts kein Garant für Qualität, und ich mag es nicht, wenn mir ein
Framework den Weg vordenkt.

Ich finde das eine recht schwierige Ausgangslage...

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

On Sat, 28 Jul 2007 04:37:59 +0200, Hadanite Marasek wrote:

>> Sobald du SSH-Zugang zu einem Server hast oder du sogar einen (V-)Server
>> angemietet hast, dreht sich die Lage komplett um. Ich kenne keinen
>> Python-Programmierer, der freiwillig wieder etwas mit PHP machen würde.
>> Es gibt einige wirklich gute Python-Webframeworks und Helferlein wie
>> z.B. CherryPy, Cheetah, Werkzeug oder Django, die einen das Leben mit
>> PHP schnell vergessen lassen. (Und mir ist das jetzt egal, wenn das auch
>> in de.comp.lang.php.misc gelesen wird.)
>
> In der Aufzählung der Frameworks liegt doch genau das Problem begründet:
> Du vergleichst Sprache mit Sprache+Framework, da dieses bei Python fast
> schon zwingend zu sein scheint (es sei denn, man legt Wert darauf, alles
> selber zu machen).

Das Framework ist bei Python doch dazu da aus einer allgemeinen
Programmiersprache eine für Webapplikationen zu machen, also das
Framework was bei PHP schon eingebaut ist, weil die Sprache aus dieser
Domäne kommt.

> Dann müsste ich als potentiell Migrationswilliger erst mal wissen,
> welches Framework, und dürfte dann erst mal dieses lernen. Und nach
> allem, was ich gesehen habe, ist die Grösse eines Projekts kein Garant
> für Qualität, und ich mag es nicht, wenn mir ein Framework den Weg
> vordenkt.

Und dann ist es ein Vorteil von PHP wenn es nur das eine eingebaute
"Grundframework" gibt? Und auch bei PHP gibt's doch dann einige
Frameworks, die man darauf aufsetzen kann, um wiederkehrende Aufgaben nicht
alle selbst neu implementieren zu müssen. Da hat man auch die Qual der
Wahl und einen "vorgedachten" Weg.

Andererseits gibt's für Python auch kleine Frameworks die einem viel
Freiheit lassen und nur Grundaufgaben erfüllen, bzw. bei den grossen kann
man in der Regel Komponenten wie Template-Engine und ORMs austauschen wenn
man möchte.

Ciao,
Marc 'BlackJack' Rintsch

In de.comp.lang.python Gerold Penz <gerold.penz [at] aon.at> wrote:
> Entweder PHP oder Python. Ich sehe keinen Vorteil darin, Python mit PHP
> zu verknüpfen. Wenn du gut mit PHP klar kommst, dann mach alles mit PHP,
> und wenn du mit Python gut klar kommst, dann mach alles mit Python.

Die Auswahl an CMSen ist für Python etwas beschränkt. Ein Grund
PHP mit Python zu verknüpfen kann sein, eine Website um eine
Anwendung zu ergängen. Verwaltung der Seiten über das PHP-CMS und
die Anwendung in Python.

Zu den Nachteilen dieser Lösung gehört das doppelte Pflegen von
Templates. Je nachdem wie man die Verknüpfung durchführen will.



Besteht ein Webauftritt nur aus einer konkreten Anwendung und
keinen (oder wenigen) Seiten, die redaktionell gepflegt werden
müssen, dann kann man sich voll auf ein gutes Python Framework
verlassen. Z. B. Django.

Wenn man kein Zope mag findet man praktisch kein CMS mit etwas
Verbreitung und größeren Community.

Ist der Verhältnis von redaktionellen Seiten zu Funktionsseiten
anders gewichtet, macht PHP wieder mehr Sinn.

Etwas wie Typo3, Joomla!, MODx usw. findet man bei Python leider
nicht. Jedes Mal das Rad selbst neu erfinden und wieder und
wieder ein spezielles CMS für jede Website programmieren ist
irgendwann nicht mehr drin, wenn man nicht nur hobbymäßig
programmiert.


--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Christian Smietana wrote:

> hat jemand Erfahrung mit der Kombination Python - PHP?

Ja.

> aus PHP in einem system()-call Python aufgerufen wird.

Dazu nutze ich lieber: http://pecl.php.net/package/python

> Anwendungslogik würde dabei objektorientiert in Python implementiert
> werden, während PHP für die Ausgabe zuständig ist.

Kommt halt immer drauf an was Du machen willst. Da wo ich die Kombi
eingesetzt hab besteht ein spezielles Umfeld (internes Firmennetzwerk)
in dem sich einfach verschiedene Dinge mit den verschiedenen Sprachen
besser machen ließen.

Allerding würde ich darauf verzichten nen stink normalen Webspace mit
sowas aufzubauen. Da eignen sich, wie bereits von anderen geschrieben,
die Frameworks der jeweiligen Sprachen besser als derartige
Kombinationen. (Der Wartungsaufwand dessen was Du Dir evtl. vorstellst
ist nicht zu unterschätzen!)

Ob Du nun mehr zu Python, Ruby, Asp, JSP, Perl oder PHP tendierst bleibt
alleine Dir überlassen. Jede der Sprachen hat Vor und Nachteile. Ein
Kombination hat zwar viele Vorteile beider Sprachen, aber auch viele
Nachteile von Beiden.

MfG, Ulf

Stefan Scholl schrieb:
> Etwas wie Typo3, Joomla!, MODx usw. findet man bei Python leider
> nicht.

Schonmal was von Zope und Plone gehört? Anscheinend nicht.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkceur [at] jabber.i-pobox.net

Hallo,

On Sat, 28 Jul 2007 13:13:06 +0200, Thomas Wittek wrote:

> Stefan Scholl schrieb:
>> Etwas wie Typo3, Joomla!, MODx usw. findet man bei Python leider nicht.
>
> Schonmal was von Zope und Plone gehört? Anscheinend nicht.
Dann lies doch mal die ganze Mail durch. Dort hat Stefan Zope (und damit
auch Plone) erstmal ausgeschlossen.

grüße,
Marek

Stefan Scholl schrieb:

> Etwas wie Typo3, Joomla!, MODx usw. findet man bei Python leider
> nicht. Jedes Mal das Rad selbst neu erfinden und wieder und
> wieder ein spezielles CMS für jede Website programmieren ist
> irgendwann nicht mehr drin, wenn man nicht nur hobbymäßig
> programmiert.

Das es für Python kein Typo3 gibt, ist eher ein Argument pro Python,
denn Typo3 ist Schrott.
Meiner Erfahrung nach setzen viele Leute CMSe ohnehin falsch ein,
nämlich, um relativ kleine Webseite abzubilden und sich davor zu
drücken, Ein- und Ausgabe strukturierter Daten zu programmieren (aber
trotzdem ordentlich Kohle scheffeln zu können).

Ein CMS hat einen klar definierten, sehr engen Bereich, in dem seine
Anwendung gerechtfertigt ist: eine grosse Seite mit überwiegend
unstrukturiertem Inhalt, der von mehreren Leuten gepflegt wird, weshalb
man ein abgestuftes Rechtesystem braucht. Berücksichtigen muss man da
dann auch den Footprint, den solche "one size fits all"-Systeme erzeugen.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Marek Kubica schrieb:
> Hallo,
>
> On Sat, 28 Jul 2007 13:13:06 +0200, Thomas Wittek wrote:
>
>> Stefan Scholl schrieb:
>>> Etwas wie Typo3, Joomla!, MODx usw. findet man bei Python leider nicht.
>> Schonmal was von Zope und Plone gehört? Anscheinend nicht.
> Dann lies doch mal die ganze Mail durch. Dort hat Stefan Zope (und damit
> auch Plone) erstmal ausgeschlossen.

Ups :) Aber warum sollte man das nicht mögen? ;)
Ok, ist vielleicht nicht der leichtgewichtigste Ansatz.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkceur [at] jabber.i-pobox.net

Hadanite Marasek schrieb:

> Ein CMS hat einen klar definierten, sehr engen Bereich, in dem seine
> Anwendung gerechtfertigt ist: eine grosse Seite mit überwiegend
> unstrukturiertem Inhalt, der von mehreren Leuten gepflegt wird, weshalb=

> man ein abgestuftes Rechtesystem braucht.

Das siehst du entschieden zu eng. Ein CMS trennt in erster Linie Inhalt
von darstellender Technik. Es ermöglicht dem Betreiber, der meist nicht=

über rudimentäre HTML-Kenntnisse hinauskommt, seine Inhalte selber zu=

pflegen.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

In de.comp.lang.python Hadanite Marasek <marasek [at] telton.de> wrote:
> Meiner Erfahrung nach setzen viele Leute CMSe ohnehin falsch ein,
> nämlich, um relativ kleine Webseite abzubilden und sich davor zu
> drücken, Ein- und Ausgabe strukturierter Daten zu programmieren (aber
> trotzdem ordentlich Kohle scheffeln zu können).
>
> Ein CMS hat einen klar definierten, sehr engen Bereich, in dem seine
> Anwendung gerechtfertigt ist: eine grosse Seite mit überwiegend
> unstrukturiertem Inhalt, der von mehreren Leuten gepflegt wird, weshalb
> man ein abgestuftes Rechtesystem braucht. Berücksichtigen muss man da
> dann auch den Footprint, den solche "one size fits all"-Systeme erzeugen.

Mir fehlt da noch ein Fazit. Ich weiß nicht genau worauf Du
hinaus willst.

>> Ein CMS hat einen klar definierten, sehr engen Bereich, in dem seine
>> Anwendung gerechtfertigt ist: eine grosse Seite mit überwiegend
>> unstrukturiertem Inhalt, der von mehreren Leuten gepflegt wird, weshalb
>> man ein abgestuftes Rechtesystem braucht. Berücksichtigen muss man da
>> dann auch den Footprint, den solche "one size fits all"-Systeme erzeugen.
>
> Mir fehlt da noch ein Fazit. Ich weiß nicht genau worauf Du
> hinaus willst.

Das Fazit sollte sich doch eigentlich aus dem zitierten Absatz ergeben.
CMSe sind geeignet für einen eng definierten Bereich und sind daher
keine Systeme, die man als Universalantwort in den Raum stellen kann.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Hallo,

danke schonmal für alle Antworten. Ich habe keine konkreten
Anforderungen zu erfüllen, sondern wollte diesen Weg einfach nutzen, um
mal tiefer in Python einzusteigen. Mein Webhoster bietet offiziell nur
PHP an, aber auf diese Weise wäre eben auch Python nutzbar. Also eine
eher experimentelle Geschichte.

Christian

In de.comp.lang.python Christian Smietana <mapson12 [at] gmx.de> wrote:
> mal tiefer in Python einzusteigen. Mein Webhoster bietet offiziell nur
> PHP an, aber auf diese Weise wäre eben auch Python nutzbar. Also eine

Wo gibt's denn noch Hoster die nur PHP haben?

Eben eine kurze Stichprobe bei Host Europe, 1&1 und Hetzner
gemacht. Die haben alle normalen Webspace (kein Root-Server) mit
Python im Angebot.


--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

In de.comp.lang.python Hadanite Marasek <marasek [at] telton.de> wrote:
>>> Ein CMS hat einen klar definierten, sehr engen Bereich, in dem seine
>>> Anwendung gerechtfertigt ist: eine grosse Seite mit überwiegend
>>> unstrukturiertem Inhalt, der von mehreren Leuten gepflegt wird, weshalb
>>> man ein abgestuftes Rechtesystem braucht. Berücksichtigen muss man da
>>> dann auch den Footprint, den solche "one size fits all"-Systeme erzeugen.
>>
>> Mir fehlt da noch ein Fazit. Ich weiß nicht genau worauf Du
>> hinaus willst.
>
> Das Fazit sollte sich doch eigentlich aus dem zitierten Absatz ergeben.
> CMSe sind geeignet für einen eng definierten Bereich und sind daher
> keine Systeme, die man als Universalantwort in den Raum stellen kann.

OK, dann also eine Ergänzung meiner Antwort - keine Kritik oder
Korrektur. Dachte ich muss irgendwie drauf reagieren.



--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Alexander Schestag schrieb:
> Diez B. Roggisch wrote:
>
>> Oder gleich auf PHP verzichten. Das meine ich ernst. Es ist nicht
>> wirklich gut.
>
> Das in einer php-Newsgroup zu äußern, dazu gehört schon Mut. ;-)

Um ehrlich zu sein war mir der Crosspost nicht bewusst. Ich haette mich
sonst etwas diplomatischer Ausgedrueckt. Aber ich habe genug PHP
programmiert, um bei meinem Urteil zu bleiben. Siehe unten.

>> Seine Vorteile sind die allgemeine Verfuegbarkeit & geringe
>> Einstiegshuerde.
>
> Umgekehrt wird ein Schuh draus. Das Märchen von der geringen
> Einstiegshürde führt zu dem Fehlschluß, PHP sei nicht gut, denn daß so
> viele Anfänger das Märchen glauben und sich von den vielen "alles ganz
> einfach" Tutorials verführen lassen, anstatt die Sprache vernünftig zu
> lernen, führt zu den allermeisten Problemen, die allesamt vor dem
> Bildschirm sitzen. Wenn man PHP gleich richtig lernt, ist es nicht
> leichter zu erlernen, als andere Scriptsprachen, und m. E. auch nicht
> schlechter.


Es tut mir leid, aber das sehe ich mit gutem Grund ganz anders. PHP ist
eine in ihrem Design erschreckend schlechte Sprache. Es gibt sogar
Leute, welche die Begriffe Sprachdesign & PHP nicht in einem Satz sagen
moechten.

Zuerstmal: ich habe mehr PHP programmiert, als mir lieb ist. Unter
anderem in PHP 4 eine Hotelbuchungsportal einer groesseren
online-hotelbuchungs-agentur. Objektorientiert, 6000+ backendklassen,
abstrahiert, mit klarer Trennung von Layout & Logik. Also eine durchaus
komplexe & im Rahmen des moeglichen sauber PHP-Anwendung.

Und dabei faellt einem dann uA folgendes unangenehm auf:

- kein binaeres API, mithin keine Erweiterungsmodule, wie sie fuer
Python, Perl und andere Sprachen gang und gaebe sind. Entweder ist ein
Modul einkompiliert, oder nicht. Und ich rede hier nicht von includes!

- keine Namensraeume

- grundsaetzlich copy-by-value-semantik, die dann mittels unnoetig
komplexer referenzen versucht wird zu kitten.

- keine verkettung von ausdruecken. also sowas wie
$a[0]->eigenschaft[index]. Wer auch nur eine einzige Vorlesung ueber
Syntaxanalyse gehoert hat, *schafft* es gar nicht sowas *nicht*
hinzubekommen!

- die PHP4-Version (relativ fruehe) von damals hat
Funktionsdefinitionen vergessen. und zwar reproduzierbar. D.h. ein
Request ging nicht durch, weil eine essentielle, vorher eingebundene
Funktion (mittels require_once oder was auch immer) nicht vorhanden war!
Und ein reload hat das dann "repariert". Der naechste reload knallte es
wieder... abzuhelfen war dem, indem man bestimmte Fehlerlevel auf
niedrigste Stufe setzte. Hallo?!? Das ist absoluter Sprachkern! Wenn
_das_ nicht geht, wundert einen gar nix mehr!

- die implementierung des einen Containertypen array, der fuer alles
herhalten muss, und dann auch noch in for-each-anweisungen Zustand
haelt, der mittels reset/clear (ich weiss nicht mehr was von beiden)
wieder zurueckgesetzt werden muss.... Dazu faellt einem eigentlich auch
nix mehr ein.

Und das sind nur wenige der Dinge, die einem User an der Oberflaeche
auffallen! Und die rein die Sprache betreffen, nicht das Vorhandesein &
Guete von Bibliotheken. Wozu sich auch noch einiges sagen liesse.

Zusaetzlich dazu ist der Autor des roadsend PHP compilers [1] ein sehr
guter Freund von mir. Ich habe ihm sogar mal geholfen,
nicht-sequentielle Stringkonkatenation zu optimieren.

Ein Projekt, von dem uebrigens der Autor von PHP behauptet hat, es waere
unmoeglich.

Und Tim hat sich notgedrungen mit der Implementierung von PHP
auseinandersetzen muessen. Wir haben da oft drueber die Koepfe
geschuettelt... memory-leaks ueberall, krude Semantik usw. Das PHP so
gut laeuft verdankt es dem Apache, der seine sub-prozesse eh alle
so-und-soviel requests killt, um eben genau der problematik zu begegnen.

Fazit: PHP _ist_ eine schlecht bzw. gar nicht designte
Programmiersprache. Was nicht heissen soll, das sie ihren Zweck fuer
bestimmte Dinge nicht erfuellt! Und ich ziehe sie zB JSPs jederzeit vor.

Aber deine Ansicht, """ Wenn man PHP gleich richtig lernt, ist es nicht
leichter zu erlernen, als andere Scriptsprachen, und m. E. auch nicht
schlechter.""" kann ich so leider nicht teilen.


MfG Diez
[1] http://www.roadsend.com/home/index.php?SMC=1&pageID=compiler

Diez B. Roggisch schrieb:
> online-hotelbuchungs-agentur. Objektorientiert, 6000+ backendklassen,
> abstrahiert, mit klarer Trennung von Layout & Logik.


Ups. 6000 Zeilen sollten das sein... 6000 klassen waeren ein kleines
bischen javaesk...

Diez

Diez B. Roggisch schrieb:

>Zuerstmal: ich habe mehr PHP programmiert, als mir lieb ist. Unter anderem
>in PHP 4 eine Hotelbuchungsportal einer groesseren
>online-hotelbuchungs-agentur.

Ja, OO in PHP 4 war halbgar und grausam. Allerdings hat man den gesamten
Bereich in PHP 5 dann nochmal radikal überarbeitet.
PHP 5 ist hier sogar weiter als Python (Interfaces, echte private- und
protected-Sichtbarkeit).

>- kein binaeres API, mithin keine Erweiterungsmodule, wie sie fuer Python,
>Perl und andere Sprachen gang und gaebe sind. Entweder ist ein Modul
>einkompiliert, oder nicht. Und ich rede hier nicht von includes!

Hmm, es gibt die Möglichkeit, Erweiterungsmodule ohne Neukompilieren
einzubinden, falls du das meinst...

> - keine Namensraeume

Ja, das ist relativ bitter. Soll aber in PHP 6 endlich auch kommen.

>- grundsaetzlich copy-by-value-semantik, die dann mittels unnoetig
>komplexer referenzen versucht wird zu kitten.

Wurde in PHP 5 für Objekte geändert.

>- keine verkettung von ausdruecken. also sowas wie
>$a[0]->eigenschaft[index]. Wer auch nur eine einzige Vorlesung ueber
>Syntaxanalyse gehoert hat, schafft es gar nicht sowas nicht hinzubekommen!

Ja, unschön.

>- die PHP4-Version (relativ fruehe) von damals hat Funktionsdefinitionen
>vergessen.

Keine Ahnung, hab ich noch nie erlebt.

--
Wolfgang Fellger

> Ja, OO in PHP 4 war halbgar und grausam. Allerdings hat man den gesamten
> Bereich in PHP 5 dann nochmal radikal überarbeitet.
> PHP 5 ist hier sogar weiter als Python (Interfaces, echte private- und
> protected-Sichtbarkeit).

Ob man das als "weiter" bezeichnet ist eine Frage der Perspektive. Als
hauptberuflicher Java-Programmierer finde ich das eher nervend. Walks
like a duck... usw. Dafuer sind Metaklassen & Dekoratoren fuer viele
Interessante Dinge gut. Das find ich persoenlich wichtiger.

Aber das ist natuerlich debattierbar, wo man da seine Praeferenzen hat.

>> - kein binaeres API, mithin keine Erweiterungsmodule, wie sie fuer Python,
>> Perl und andere Sprachen gang und gaebe sind. Entweder ist ein Modul
>> einkompiliert, oder nicht. Und ich rede hier nicht von includes!
>
> Hmm, es gibt die Möglichkeit, Erweiterungsmodule ohne Neukompilieren
> einzubinden, falls du das meinst...

AFAIK musste ich zB fuer Oracle-Support immer den Compiler anwerfen &
das komplette Ding neu kompilieren - nicht einfach nur eine Erweiterung.
Wie bindet man sowas denn dann ein?

>> - keine Namensraeume
>
> Ja, das ist relativ bitter. Soll aber in PHP 6 endlich auch kommen.
>
>> - grundsaetzlich copy-by-value-semantik, die dann mittels unnoetig
>> komplexer referenzen versucht wird zu kitten.
>
> Wurde in PHP 5 für Objekte geändert.

>> - keine verkettung von ausdruecken. also sowas wie
>> $a[0]->eigenschaft[index]. Wer auch nur eine einzige Vorlesung ueber
>> Syntaxanalyse gehoert hat, schafft es gar nicht sowas nicht hinzubekommen!
>
> Ja, unschön.
>
>> - die PHP4-Version (relativ fruehe) von damals hat Funktionsdefinitionen
>> vergessen.
>
> Keine Ahnung, hab ich noch nie erlebt.

Davor & danach auch nie wieder... letztlich war das Ding wohl zu
komplex. Aber passieren darf sowas trotzdem nicht.

Diez

Diez B. Roggisch schrieb:

> Davor & danach auch nie wieder... letztlich war das Ding wohl zu
> komplex. Aber passieren darf sowas trotzdem nicht.

6000 Zeilen sind nun wirklich nicht komplex.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:
> Diez B. Roggisch schrieb:
>
>> Davor & danach auch nie wieder... letztlich war das Ding wohl zu
>> komplex. Aber passieren darf sowas trotzdem nicht.
>
> 6000 Zeilen sind nun wirklich nicht komplex.

Um so schlimmer... und das waren 6000 Zeilen reiner Code, seiten +
templates natuerlich nochmal extra.

Diez

Hadanite Marasek schrieb:
> In der Aufzählung der Frameworks liegt doch genau das Problem begründet:
> Du vergleichst Sprache mit Sprache+Framework, da dieses bei Python fast
> schon zwingend zu sein scheint (es sei denn, man legt Wert darauf, alles
> selber zu machen). Dann müsste ich als potentiell Migrationswilliger
> erst mal wissen, welches Framework, und dürfte dann erst mal dieses
> lernen. Und nach allem, was ich gesehen habe, ist die Grösse eines
> Projekts kein Garant für Qualität, und ich mag es nicht, wenn mir ein
> Framework den Weg vordenkt.
>
> Ich finde das eine recht schwierige Ausgangslage...

Wer die Wahl hat, hat die Qual. Das Stimmt.

Seit ein paar Wochen verwende ich das in Python geschrieben Webframework
Django. Es bietet einiges mehr als PHP. Django denkt dir deine Umsetzung
nicht vor. Es bietet dir verschiedene Bausteine, die du, wenn du willst
benutzen kannst:
- OR-Mapping
- Sessions
- Authentication
- Admininterface
- mod_python, scgi Support
- Templatesprache (nutze ich nicht)


Das, nur so als Hinweis, falls jemand auf der Suche nach einem Framework
ist.

Gruß,
Thomas

On Sat, 28 Jul 2007, Gerold Penz wrote:

> Der Vorteil den PHP bieten kann ist: es lässt sich sehr leicht in den Apachen
> integrieren. Man kann einen Server für "viele" einrichten, ohne jedem
> Webspace-Kunden irgendwelche Ausführberechtigungen geben zu müssen. Das Leben
> eines Providers ist mit PHP heutzutage viel einfacher als mit Python.

Ich fürchte, das habe ich nicht verstanden. Wie erreicht man es, dass ein
einem Server "für viele" jeder nur seine eigenen Daten anschauen, ändern
oder zerschießen kann? Wir knobeln schon eine Weile, aber uns fällt
keine unmittelbar einleuchtende Lösung ein. Nein, Safe-Mode ist keine.

--
Helmut Richter

Helmut Richter wrote:
> On Sat, 28 Jul 2007, Gerold Penz wrote:
>
>> Der Vorteil den PHP bieten kann ist: es lässt sich sehr leicht in de=
n Apachen
>> integrieren. Man kann einen Server für "viele" einrichten, ohne jede=
m
>> Webspace-Kunden irgendwelche Ausführberechtigungen geben zu müssen=
=2E Das Leben
>> eines Providers ist mit PHP heutzutage viel einfacher als mit Python.

> Ich fürchte, das habe ich nicht verstanden. Wie erreicht man es, dass=
ein
> einem Server "für viele" jeder nur seine eigenen Daten anschauen, ä=
ndern
> oder zerschießen kann? Wir knobeln schon eine Weile, aber uns fällt=

> keine unmittelbar einleuchtende Lösung ein. Nein, Safe-Mode ist keine=
=2E

=C4hm, und was machen dann Hoster? open_basedir und safe mode sind nur
Krücken, ja. open_basedir kann m. E. ein bißchen zusätzlichen Schut=
z
geben, ist aber auch nicht sicher (oder ist der Bug mittlerweile
gefixt?) und bezieht sich ohnehin nur auf PHP. Willst du generelle
Zugriffsbeschränkungen für Webs, mußt du das letztlich über die
Rechteverwaltung auf Dateisystemebene regeln. Zumindest unter Linux ist
das gar kein Problem.

Grüße,

Alex

On Fri, 10 Aug 2007, Alexander Schestag wrote:

> Ähm, und was machen dann Hoster?

Genau das wüsste ich gerne.

> Willst du generelle Zugriffsbeschränkungen für Webs, mußt
> du das letztlich über die Rechteverwaltung auf Dateisystemebene regeln.
> Zumindest unter Linux ist das gar kein Problem.

Nicht ganz einfach, wenn man eine Farm aus mehreren physischen Servern
hat. Man braucht dann ein *verteiltes* Filesystem, das ACLs beherrscht.
Den Fileserver wollen wir nicht unbedingt selber bauen (das wären dann
zwei Fileserver, die sich wegen Ausfallsicherheit gegenseitig überwachen
müssen und *beide* physischen Zugriff auf die Platten haben müssen), wenns
NAS-Filer fertig gibt ...

Ich sehe ein, dass das Problem, das ich ansprechen wollte, von so vielen
Randbedingungen abhängt, dass es wenig sinnvoll war, es hier zur Sprache
zu bringen, wo jeder ein anderes System fährt, sehr wenige mehr als einen
Apachen mit den gleichen Daten betreibt und Fileserver auch nicht so
verbreitet sind. Also Kommando zurück, es sei denn es liest wirklich ein
Hoster mit mindestens ein paar hundert Kunden mit, der gewillt ist, etwas
über seine Konfiguration zu verraten. Das wäre spannend.

--
Helmut Richter

Hallo Helmut,

Helmut Richter wrote:
> On Fri, 10 Aug 2007, Alexander Schestag wrote:
>
>> =C4hm, und was machen dann Hoster?

> Genau das wüsste ich gerne.

Eigentlich nur das, was ich unten beschrieben habe. Deine Konstellation
ist m. E. im normalen Hosting-Kontext kaum anzutreffen, insbesondere
nicht bei großen Massen-Hostern. Sowas trifft man m. E. eher in Firmen =

an, die eigene Server betreiben, denn bei normalen Hostern.

>> Willst du generelle Zugriffsbeschränkungen für Webs, mußt
>> du das letztlich über die Rechteverwaltung auf Dateisystemebene rege=
ln.
>> Zumindest unter Linux ist das gar kein Problem.

> Nicht ganz einfach, wenn man eine Farm aus mehreren physischen Servern =

> hat. Man braucht dann ein *verteiltes* Filesystem, das ACLs beherrscht.=


ACK! Aber das ist m. E. beim Hosting nicht Standard. Meistens hast du da =

*einen* Webserver, auf dem halt etliche Webs als vhosts laufen.
Natürlich haben die meisten Hoster mehrere Server, die aber wohl nix
miteinander zu tun haben. Und da ist die Konfiguration wirklich relativ
einfach.

[...]

> Ich sehe ein, dass das Problem, das ich ansprechen wollte, von so viele=
n
> Randbedingungen abhängt, dass es wenig sinnvoll war, es hier zur Spra=
che
> zu bringen, wo jeder ein anderes System fährt, sehr wenige mehr als e=
inen
> Apachen mit den gleichen Daten betreibt und Fileserver auch nicht so
> verbreitet sind. Also Kommando zurück, es sei denn es liest wirklich =
ein
> Hoster mit mindestens ein paar hundert Kunden mit, der gewillt ist, etw=
as
> über seine Konfiguration zu verraten. Das wäre spannend.

Da gibt es nicht viel zu verraten, weil deine Konstellation von den
meisten Hostern wohl kaum gefahren wird. Meines Wissens haben große
Hoster bis zu 20.000 (!) Webs auf einem einzigen Server und fahren
*keine* solche Konstellation. Zu dem Schleuderpreis, für den du dort
Webspace und Domains bekommst, wäre das nicht zu machen. Wie gesagt,
deine Konstellation halte ich eher im Firmen-Kontext für wahrscheinlich=
,
wenn die Firma eigene Server betreibt.

Grüße,

Alex