testen, ob Python.h vorhanden

[CM]

Hoi,

ich bin gerade dabei das Setup eines Paketes von mir so zu verbessern, daß es wirklich einjeder installieren kann.
U. a. prüft jetzt setup.py, ob alle Abhängigkeiten erfüllt sind und gibt ggf. Info darüber wie best. Abhängigkeiten gelöst werden können. Bei Pythonmodulen: Kein Problem. Aber wie teste ich darauf ob die Python dev.-Files vorhanden sind? Den meisten Leuten sagen entsprechende Nachrichten vom Compiler nichts, also: Wie teste ich, ob "#include <Python.h>" funktionieren wird, so daß das Setupskript entsprechend warnen kann? (OS-unabhängig natürlich .

Gruß,
Christian

[noise]

Hi, machst du das mit distutils?

[CM]

Ja. Ich überlege gerade, ob es nicht besser ist einfach draufloszukompilieren und Fehler abzufangen. Ist zwar ein wenig aufwändig, wenn es sauber sein soll, aber machbar. Oder gibt es in distutils eine builtin-Lösung? (Habe nichts gefunden.)

Gruß,
Christian

[Gnushi]

Hi!

wie teste ich darauf ob die Python dev.-Files vorhanden sind?

Kleiner Vorschlag:

Das geht auf unixähnlichen Systemen mit dem Gespann aus 'automake' und 'autoconf'. Letztlich wird ein Shellskript namens 'configure.sh' erzeugt, welches dann den Code zum Prüfen enthält.

Alternative:
Du könntest schauen, welche Version von Python installiert ist. Anschließend findest Du heraus, ob /usr/include/pythonPYTHONVERSION/Python.h oder
/usr/local/include/pythonPYTHONVERSION/Python.h vorhanden ist.

GnuShi

[CM]

automake und autoconf oder configure-Skripte vertragen sich aber irgendwie schlecht mit einer Lösung mittels distutils.

Die Alternative wäre natürlich rel. unproblematisch - aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)

Gruß,
Christian

[noise]

Ja. Ich überlege gerade, ob es nicht besser ist einfach draufloszukompilieren und Fehler abzufangen. Ist zwar ein wenig aufwändig, wenn es sauber sein soll, aber machbar. Oder gibt es in distutils eine builtin-Lösung? (Habe nichts gefunden.)

Gruß,
Christian

Ah OK, dann ist alles klar

Die Alternative wäre natürlich rel. unproblematisch - aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)

Gruß,
Christian

Garnicht, den das macht alles für dich distutils
Und zwar: Python wird auf Windows per Binary-Setup installiert und dabei trägt sich einiges an Infos in die Registry ein. Der Pfad zu python, etc. Und in jeder Installation wird auch das include und libs mit installiert. Sprich es sind alle Informationen und Files vorhanden um eine Python-Extension zu bauen.

Das einzige was du zusätzlich mache kannst ist in der README einzutragen das Windows user die kein Visual C++ habe mingw installieren und, ``python setup.py build -c mingw32`` + ``python setup.py install`` eintragen um mit mingw das ganze zu backen. Damit habe ich gute Erfahrung und konnte bisher alle extensions auf Windows backen. OT: Es heißt ja das man eigentlich die extensions mit Visual C++ backen muss, aber mein erfahrung und die der anderen lehren uns das eigentlich fast alles sich mit einem aktuellen mingw auch backen lässt.

Kurz: Wenn Python regulär auf Windows installiert wurde und der User (besser Entwickler) den Python Pfad in die Umgebungsvariable eingetragen hat, genügt für ihm ein ``python setup.py`` bzw. ``python setup.py build -c mingw32`` + ``python setup.py install``. Den Rest erledigt distutils.

Optional kannst du wenn du willst für Window user **mit** distutils eine setup.exe backen, in der alle extensions Vorkompiliert sind. Der nachteil ist, das du für jede von dir unterstützte Python Version so eine exe backen musst, da ja immer gegen die jeweilige Python lib gelinkt werden muss (Siehe wxPython). Das ist für dich als Entwickler Mehraufwand aber für den Entwickler der deine Lib nutzt viel praktischer

HTH
noise

P.S.: Ich hoffe ich hab nicht all zuviel geschrieben.

EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient

[Rebecca]

EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient

Unter Linux stecken Header-Dateien etc. meist in extra Devel-Paketen und werden standardmaessig nicht mitinstalliert.

CM, du koenntest ein kleines Testprogramm compilieren:

Code: Alles auswählen

#include <Python.h>
int main(){}

Und dann schauen, ob ein Fehler auftritt und in der Ausgabe "Python.h" auftaucht...

[noise]

EDIT: PPS: Auf Python.h brauchst du mit distutils nicht zu testen, den wenn einer so dumm ist bei seinem installierten Pyhon das include Verzeichnis zu löschen, hat er es nicht anders verdient

Unter Linux stecken Header-Dateien etc. meist in extra Devel-Paketen und werden standardmaessig nicht mitinstalliert.

Hallo Rebecca,

das trifft auch auf distutils zu In python-dev (auf debian basierende), python-devel, ...Sprich, wenn auf nem debian like system kein Devel installiert ist, kann man es ehe nicht mit distutils installieren, da es schlicht und einfach fehlt.

Davon abgesehen:

aber wie mache ich das auf Windows? Gibt es da ebenfalls spez. Pfade? (Ahnungslosigkeit meinerseits - habe noch nie mit diesem OS *richtig* gearbeitet.)

Und darauf habe ich mich bezogen. Aber auch hier: Wer Python-Entwickler auf Linux ist und zu dumm ist sich **nicht** die devels installiert, hat es nicht anders verdient Sorry, aber sehe ich leider so und ich hoffe es kommt nicht zu pampig rüber. Weil hin und wider installiert man ja auf Linux Libs die ebenfalls das backen einer Extension erfordern...

[gerold]

Hallo Christian!

Du kannst mit den distutils auch Installationsdateien für Windows erstellen. Diese sind dann ausführbare EXE-Dateien.

Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es! Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).

Im Programm prüfst du die Plattform ab und lädst nach Bedarf die Win32- oder die Win64-DLL.

Das gilt jetzt aber nur, wenn du ein Python-Paket erstellen möchtest. Wenn du ein eigenständiges Programm schreiben möchtest, dann bist du mit den distutils mehr als schlecht bedient. Denn alles wird in den "site-packages"-Ordner installiert und es gibt keine Möglichkeit, den Installationsordner in einem Windows-Setup einstellbar zu machen. Das ginge zwar in Ansätzen, wenn man ``python setup.py install`` aufruft, aber das ist ja nicht der einfachste Weg für den Benutzer.

Ich habe vor einiger Zeit mal das Programm InstallJammer http://www.installjammer.com/ entdeckt. Damit soll man angeblich (ich habe es leider noch nicht ausprobiert) Programminstallationen für Windows und Linux erstellen können. Was ich bis jetzt sagen kann: Es scheint wirklich toll zu sein und wird laufend weiterentwickelt.

mfg
Gerold

[CM]

Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es! Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).

Tja, aber das erfordert a) Zugang zu einem Windowsrechner mit Python und b) Muße mich damit auseinanderzusetzen.

Also, ich habe ein Paket geschrieben - ganz bewußt. Und ich richte mich an Wissenschaftler, keine Programmierer, aber mit ein paar Beispielskripten sollten sie eigentlich loslegen können. Also braucht ich wohl ggf. einen engagierten Nutzer, das auf Windows mal vorzubacken.

Die Idee auf mingw-hinzuweisen finde ich gut.

Überhaupt waren das bisher tolle Kommentare. Vielen Dank euch allen! Werde mir das mal durch den Kopf gehen lassen.

Gruß,
Christian

[Rebecca]

das trifft auch auf distutils zu In python-dev (auf debian basierende), python-devel, ...Sprich, wenn auf nem debian like system kein Devel installiert ist, kann man es ehe nicht mit distutils installieren, da es schlicht und einfach fehlt.

Mmh:

Code: Alles auswählen

> apt-file search distutils
python2.4: usr/lib/python2.4/distutils/README
python2.4: usr/lib/python2.4/distutils/__init__.py
python2.4: usr/lib/python2.4/distutils/archive_util.py
python2.4: usr/lib/python2.4/distutils/bcppcompiler.py
python2.4: usr/lib/python2.4/distutils/ccompiler.py
python2.4: usr/lib/python2.4/distutils/cmd.py
python2.4: usr/lib/python2.4/distutils/command/__init__.py
python2.4: usr/lib/python2.4/distutils/command/bdist.py
python2.4: usr/lib/python2.4/distutils/command/bdist_dumb.py
...

Code: Alles auswählen

> apt-file search Python.h
python2.4-dev: usr/include/python2.4/Python.h

[noise]

Hallo Christian!

Du kannst mit den distutils auch Installationsdateien für Windows erstellen. Diese sind dann ausführbare EXE-Dateien.

Das schrieb ich bereits:

Optional kannst du wenn du willst für Window user **mit** distutils eine setup.exe backen, in der alle extensions Vorkompiliert sind. Der nachteil ist, das du für jede von dir unterstützte Python Version so eine exe backen musst, da ja immer gegen die jeweilige Python lib gelinkt werden muss (Siehe wxPython). Das ist für dich als Entwickler Mehraufwand aber für den Entwickler der deine Lib nutzt viel praktischer

Aber zu folgenden Punkte ein par Anmerkungen, wenn sie gestattet sind:

Unabhängig davon: Wenn du etwas einem Windows-User nicht zutrauen kannst, dann, dass sich dieser ein MINGW installiert um sich die DLLs über die distutils bauen zu können. Vergiss es!

Sorry, aber mit verlaub, das ist Schwachsinn! Wenn er eine Library schreibt (Und das habe ich verstanden, korrigiere mich wenn es anders ist) die Python-Entwickler benutzten können, dann kann man es schon von einem Entwickler erwarten das er es hinkriegt ein par Bunte Knöpfe zu drücken um mingw zu installieren! Oder ist hier zufällig einer der mit Python auf nem Windows-System arbeitet der das nicht hinkriegt!?

Gerold, verstehe mich bitte nicht falsch, aber wir reden hier von Programmierern und nicht von durchschnittlichen Benutzern die gerade mal wissen wie ein E-Mail Programm und office funktionieren.

Das funktioniert nicht. Liefere lieber fertig gebaute DLLs für Windows mit. Einmal für Win32 und einmal für Win64 (wenn du auch schon auf Python64 vorbereitet sein willst).

**snipp**
Im Programm prüfst du die Plattform ab und lädst nach Bedarf die Win32- oder die Win64-DLL.

Das gilt jetzt aber nur, wenn du ein Python-Paket erstellen möchtest.

Ja, aber er muss, und das habe ich auch erwähnt, das er auch für alle von Ihm unterstützten Python-Versionen eine extra setup.exe backen muss. Konkret: Wenn er Python 2.3, 2.4, 2.5 unterstützen möchte muss er für alle diese dreien eine setup.exe backen. Denn es muss immer gegen die jeweilige `libpython*.a` gelinkt werden, sonst funktioniert es nicht. Das ist, wie ich schon schrieb, ein Mehraufwand. Natürlich ist es aus unserer Sicht die später seine Libarary benutzten bequemer, aber was spricht gegen ein ``python setup.py build -c mingw32`` + ``python setup.py install``? Soviel mehraufwand ist es doch auch nun wider nicht. Und wenn er es in der README bzw. INTALL schreibt wie man das auf Windows hinkriegt, das sollte man schon von einem Programmierer (und nicht nur von dem) erwarten das er mal ein Par Minuten seiner Zeit zum lesen opfert.

Wenn du ein eigenständiges Programm schreiben möchtest, dann bist du mit den distutils mehr als schlecht bedient.

Ja wenn es nur durchschnittliche Benutzer sind, sind solche oft damit überfordert.

Denn alles wird in den "site-packages"-Ordner installiert und es gibt keine Möglichkeit, den Installationsordner in einem Windows-Setup einstellbar zu machen. Das ginge zwar in Ansätzen, wenn man ``python setup.py install`` aufruft, aber das ist ja nicht der einfachste Weg für den Benutzer.

Mit Windows-Setup meinst du ein Binary-Setup gebacken von distutils? Wenn nicht dann, auch auf Windows kann man einstellen das es wo anders als auf in den site-packages Ordner Installiert wird (Natürlich nicht wenn es ein Binary-Setup gebacken von distutils ist). Es langt schlicht und einfach ein ``--prefix="c:\my programm"``.

Ich habe vor einiger Zeit mal das Programm InstallJammer http://www.installjammer.com/ entdeckt. Damit soll man angeblich (ich habe es leider noch nicht ausprobiert) Programminstallationen für Windows und Linux erstellen können. Was ich bis jetzt sagen kann: Es scheint wirklich toll zu sein und wird laufend weiterentwickelt.

Sorry aber ich finde ein Binary-Setup für Linux mehr als schlecht. Gerade das ist doch das schöne an Python, das ich kleine Programme installieren kann die in ausführbaren source code vorliegen. Also warum sotte ein ernsthafter Linux-Benutzer eine gefreezte variante gegenüber eine in source code Form bevorzugen, bzw. eine Binary Setup gegenüber eines setups von distutils?

Sind die Leute heute echt mit einem ``python setup.py install`` überfordert? Auch verstehe ich nicht wie es kommt das alle denken das Windows User alle voll DAUs sind

my 0.1€

noise

[noise]

Mmh:

Rebecca, es ist allgemein bekannt das distutils nicht auf allen (Sprich auf einigen schon aber noch lange nciht auf jeden) Linuxen standardmäßige dabei ist sondern über die devels zu beziehen ist.

Bein installieren der devels wird dann distutils **selbstverständlich** dort installiert wo man es dann z.B. über PYTHONPATH beziehen kann (in deinem Fall `usr/lib/python2.4/distutils`).

Davon abgesehen ist auf meinen debian-like system distutils NUR über die entsprechenden devels zu beziehen und nicht im Standard package dabei. Beweisen kann ich es selbstverständlich nicht, aber du kannst ruhig mal andere debian und debian-like user fragen.

[veers]

Sorry aber ich finde ein Binary-Setup für Linux mehr als schlecht. Gerade das ist doch das schöne an Python, das ich kleine Programme installieren kann die in ausführbaren source code vorliegen. Also warum sotte ein ernsthafter Linux-Benutzer eine gefreezte variante gegenüber eine in source code Form bevorzugen, bzw. eine Binary Setup gegenüber eines setups von distutils?

Da kann ich mich nur anschliessen.

Auch verstehe ich nicht wie es kommt das alle denken das Windows User alle voll DAUs sind

Weil es oft so ist Abgesehen davon fehlen Windows User die Tools um "mal schnell" Software zu installieren. Ein weiterer Punkt is Gewohnheit. Windows User wollen ihre installer. Linux User wollen entweder Packete oder den Source.

[noise]

Weil es oft so ist Abgesehen davon fehlen Windows User die Tools um "mal schnell" Software zu installieren. Ein weiterer Punkt is Gewohnheit. Windows User wollen ihre installer. Linux User wollen entweder Packete oder den Source.

Naja, OK, das stimmt schon. Aber dennoch denke ich das es schlicht ein Klischee ist das alle Windows User DUAs sind (OK, das hast du zwar nicht gesagt, aber das ist ja so die allgemeine Haltung im Web). Natürlich kenne ich einige Windows DAUs aber bestimmt auch genauso viele Linux DAUs die ohne DE nicht klar kommen.


Christian, ich würde mich bereit erklären deine Lib mal auf Windows zu backen und zu schauen ob es Funktioniert oder ob du an einigen Stellen unportablen C-Code geschrieben hast.

[gerold]

Oder ist hier zufällig einer der mit Python auf nem Windows-System arbeitet der das nicht hinkriegt!?

Hallo noise!

Ich glaube, dass unter unseren 4000 Mitgliedern mindestens 500 dabei sind, die das nicht ohne Hilfe oder stundenlangem Fluchen hin kriegen. Es fängt schon damit an, die richtige Installationsdatei für MINGW zu finden.

http://gelb.bcom.at/trac/misc/wiki/Tuto ... stallieren

@All:
Ich halte es auch nicht für ideal, für Linux ein Setup-Programm zu erstellen. Aber es hält einen ja niemand davon ab, zusätzlich auch Pakete für die einzelnen Linux-Distributionen zusammen zu stellen. Und wenn jemand keine Ahnung hat, wie man diese Pakete macht, dann ist es immer noch besser zumindest ein Setup für alle Linux-Distris zur Verfügung zu haben.

Man kann OpenOffice unter Linux auch über ein Setup installieren. Man kann es aber in jeder Distribution auch über den Paketmanager installieren. Die eine Möglichkeit schließt die andere Möglichkeit also nicht aus.

Und dass Christian ein Python-Paket verteilen will, ist mir beim Überfliegen der Beiträge nicht aufgefallen. Aber ich bin immer noch der Meinung, dass distutils für ein eigenständiges Programm nicht zu gebrauchen ist. Auch wenn man den Präfix mit angibt, hat man unterhalb dieses Ordners kaum eine Möglichkeit auf die Verteilung der Dateien Einfluss zu nehmen.

mfg
Gerold

[BlackJack]

@noise: Vielleicht liege ich auch falsch, aber wenn die Zielgruppe von CM's Python-Bibliothek Naturwissenschaftler sind, dann darfst Du davon ausgehen, dass ein guter Teil davon das mit mingw nicht so einfach hinbekommt. Deren Programme willst Du auch nicht sehen.

[noise]

Oder ist hier zufällig einer der mit Python auf nem Windows-System arbeitet der das nicht hinkriegt!?

Hallo noise!

Ich glaube, dass unter unseren 4000 Mitgliedern mindestens 500 dabei sind, die das nicht ohne Hilfe oder stundenlangem Fluchen hin kriegen. Es fängt schon damit an, die richtige Installationsdatei für MINGW zu finden.

Ich möchte hier jetzt kein flame anfangen, aber ich kann das von technisch versierten Benutzern absolut nicht nachvollziehen.

1. Man gehe auf http://www.mingw.org/
2. Macht sein Augen auf...klickt auf "Download" und danach auf "Installing MinGW"
3. Man lese sich das aufmerksam durch und klickt danach auf "Download page."...
4. und kommt auf die sourceforge http://sourceforge.net/project/showfile ... up_id=2435
5. Augen auf...Links klickt man auf "Automated MinGW Installer" ladet sich die MinGW-5.1.3.exe, startet sie und augen auf und klick, klick....

Entschuldigt bitte wenn das etwas pampig rüberkommt, aber mir kann keiner hier erzählen das technisch versierte benutzter nicht in der Lage sind Ihre Augen aufzumachen und ein wenig zu lesen! Diese 5 von mir beschriebenen schritte sind sowas von trivial und der Automated-Installer erledigt alles selbständig (das war früher anders)! Das einzige was man noch machen muss ist den Pfad zu den Binarys in die Umgebungsvariable einzutragen und DAS kann ich wohl von einem Programmierer erwarten oder? -- Davon abgesehen ist das von mir eben beschriebene Szenario im groben, Standard wenn man neue open source software auf Windows Kisten installiert (Seite anschauen (Installation Vorgang und was man beachten muss) -> Und den Link anklicken der einem zu sourceforge o.ä. führt -> download -> klick, klick....)

Wie gesagt ich rede hier nicht von dem durchschnittlichen Benutzer der sein Office macht, Internet stöbert, E-Mail, etc. Ne, der will in erster Linie mit seinem PC arbeiten. Das respektiere ich und gestehe es ihm auch zu das er keine Lust/Zeit/Interesse dafür hat sich tiefer mit dem PC zu beschäftigen. Ist ja normal, wenn ich auto fahren will muss ich nicht wissen wie das Auto im Detail funktioniert.

Aber wir reden hier von Programmieren und die erschaffen Programme am PC für sich und andere, was absolut nicht trivial ist und sehr komplex werden kann. Das heißt da geht für Ihre Lust/Zeit/Interesse für den PC und die Programierung sehr viel Zeit drauf und da kann ich und ihr doch erwarten das so einer mingw installiert bekommt, oder? Wenn nicht, da frage ich mich ernsthaft wie diese "Programmierer" selbständig Programmieren können? Und selbst wenn es wirklich Probleme gibt (Wie ich letztens mit einer selbst geschriebenen C-Extension), wo ist das Problem in einem passenden Forum/NG/ML nachzufragen?

Mein Post mag zwar arrogant und überheblich erscheinen, aber ich denke mein Standpunkt ist verständlich, oder? Auch möchte ich mich in keinster weise hervortun und sage auch offen das ich auch nicht alles als Hobby-Programmierer verstehe was ich fürs programmieren benötige, und auf die Hilfe von anderen Angewiesen bin. Aber ich lese mir erstmal alles notwendige durch und wenn ich absolut nicht weiterkomme, sei es weil ich ein Brett vorm Kopf oder etwas übersehen habe, da frage ich in einem Forum/NG/ML/IRC nach.

Ich möchte mich dennoch für diesen Flame entschuldigen, aber das musste ich mal loswerden.

[BlackJack]

Die Frage ist von was für Programmierern wir reden. Es gibt Leute die sehen das ganze einfach nur als notwendiges Übel um zu Ergebnissen zu kommen und wollen das so kurz und schnell wie möglich hinter sich bringen. Programme mit Kommandozeile sind Igitt und Python==IDLE. Dann muss man vielleicht noch in das richtige Verzeichnis wechseln, dabei kommt man dann das erste mal mit diesem komischen Konzept des aktuellen Verzeichnisses in Kontakt.

Es gibt eine Menge Leute die Programmieren müssen, aber eigentlich keine Programmierer sind.

[CM]

@noise: Vielleicht liege ich auch falsch, aber wenn die Zielgruppe von CM's Python-Bibliothek Naturwissenschaftler sind, dann darfst Du davon ausgehen, dass ein guter Teil davon das mit mingw nicht so einfach hinbekommt. Deren Programme willst Du auch nicht sehen.

LOL*

Aber davon ab: Ich bleibe dabei: Ich schreibe ein Paket und KEIN Programm. Der Grund ist banal: Ich bin zu dumm ein Programm zu schreiben, daß alle Möglichkeiten einer bestimmten Simulation abdeckt, aber clever genug ein Paket zu schreiben, damit Leute für Ihre Situation was zusammenstückeln können. (Und, nein: Eine GUI, die das macht werde ich nicht entwerfen.)

Meine Entscheidung bei distutils zu bleiben ist rein pragmatisch: Es ist Standard und einfach. Und sofern Leute alle Pakete haben ist die Installation, aber so was von einfach ... Und: Für alle Pakete von denen meines abhängig ist gibt es Windowsinstaller.

Leute, die etwas länger im Geschäft sind, nutzen sowieso zu 95 % irgendein UNIX-Derivat. Bei Studenten und "sonstigem Nachwuchs" sieht es genau umgekehrt aus. Also sollte auch unter Windows eine Installation möglich sein.

@noise: Vielen Dank für das Angebot den C-Code zu testen, aber ich muß es ablehnen. 1. habe ich mich an die API gehalten und ansonsten Standard ANSI-C benutzt (was nichts heißt, ja, aber was soll man sonst noch machen?) und 2. werde ich den Algorithmus nicht rausrücken, bevor ich ohnehin veröffentliche.

Gruß,
Christian

*PS: Es gibt bei mir unittests -- und ich arbeite nicht mit obskuren Dateiformaten.
PPS Wußte gar nicht, das man mit so einer Frage eine so leidenschaftliche Debatte auslösen kann ...