Python und Windows
Hi,
warum muss ich bei der "Referenz-Implementierung" des Interpreters für Windows die Umgebungsvariablen für die Pfade setzen, u.a. auch für das Verzeichnis \Scripts ? Ist das gewollt oder schlicht ein Bug ?
Servus,
On Mon, 28 Oct 2013 15:59:20 +0100 Alexander Langer alexander.langer@address.invalid wrote:
warum muss ich bei der "Referenz-Implementierung" des Interpreters für Windows die Umgebungsvariablen für die Pfade setzen, u.a. auch für das Verzeichnis \Scripts ? Ist das gewollt oder schlicht ein Bug ?
Huch, was für Umgebungsvariablen meinst du?
grüße, Marek
On Oct 28, 2013, at 10:20 PM, Marek Kubica marek@xivilization.net wrote:
Servus,
On Mon, 28 Oct 2013 15:59:20 +0100 Alexander Langer alexander.langer@address.invalid wrote:
warum muss ich bei der "Referenz-Implementierung" des Interpreters für Windows die Umgebungsvariablen für die Pfade setzen, u.a. auch für das Verzeichnis \Scripts ? Ist das gewollt oder schlicht ein Bug ?
Huch, was für Umgebungsvariablen meinst du?
Ich denke mal, er mein PATH. Und ja, das ist ein Feature. Kann man drueber debattieren, aber ein Bug ist es nicht.
Diez
On Mon, 28 Oct 2013 22:56:18 +0200 "Diez B. Roggisch" deets@web.de wrote:
Ich denke mal, er mein PATH. Und ja, das ist ein Feature. Kann man drueber debattieren, aber ein Bug ist es nicht.
Dafür hat der Installer wenn ich mich richtig erinnere eine Einstellung, den Installationspfad in PATH einzutragen. Ob das auf Windows ein sinnvolles vorgehen ist, sei mal dahingestellt.
grüße, Marek
On Mon, 28 Oct 2013 21:58:45 +0100 Marek Kubica wrote:
On Mon, 28 Oct 2013 22:56:18 +0200 "Diez B. Roggisch" deets@web.de wrote:
Ich denke mal, er mein PATH. Und ja, das ist ein Feature. Kann man drueber debattieren, aber ein Bug ist es nicht.
Dafür hat der Installer wenn ich mich richtig erinnere eine Einstellung, den Installationspfad in PATH einzutragen. Ob das auf Windows ein sinnvolles vorgehen ist, sei mal dahingestellt.
Umpf, Du moechtest aber doch sicher, dass dein Terminal unter Windows die Python Binary findet wenn Du "python" tippst, oder nicht? Wie soll das denn anders funktionieren?
Oder hab ich dich jetzt komplett falsch verstanden?
Johannes
On Oct 28, 2013, at 11:12 PM, Johannes Findeisen mailman@hanez.org wrote:
On Mon, 28 Oct 2013 21:58:45 +0100 Marek Kubica wrote:
On Mon, 28 Oct 2013 22:56:18 +0200 "Diez B. Roggisch" deets@web.de wrote:
Ich denke mal, er mein PATH. Und ja, das ist ein Feature. Kann man drueber debattieren, aber ein Bug ist es nicht.
Dafür hat der Installer wenn ich mich richtig erinnere eine Einstellung, den Installationspfad in PATH einzutragen. Ob das auf Windows ein sinnvolles vorgehen ist, sei mal dahingestellt.
Umpf, Du moechtest aber doch sicher, dass dein Terminal unter Windows die Python Binary findet wenn Du "python" tippst, oder nicht? Wie soll das denn anders funktionieren?
Oder hab ich dich jetzt komplett falsch verstanden?
http://docs.python.org/2/using/windows.html#excursus-setting-environment-var...
Und du moechstest doch sicher, dass nach Installation von Python 3 nach Python 2 nicht ploetzlich installierte Skripte kaputt sind, weil der Pfad veraendert wird?
Am Ende ist das eine Abwaegungssache, ich bin da selbst gar nicht zwingend fuer das eine oder ander (ich vermeide Windows eh, wo's geht und aergere mich demensprechend ueber eine Menge Idiosynkratien), aber es ist definitiv eine *bewusste* Entscheidung, den Pfad nicht anzufassen.
Was im uebrigen auch unter UNIX eigentlich nix und niemand tut - da wird halt stattdessen in ein Standardverzeichnis ein Link oder Executable gepackt, etwas, dass es so unter Windows nicht so richtig gibt. Denn wenn alle Programme zB in "Program Files" installieren, dann ist da ziemlich Muellhalde…
Diez
On 28.10.2013 22:20, Diez B. Roggisch wrote:
http://docs.python.org/2/using/windows.html#excursus-setting-environment-var...
Und du moechstest doch sicher, dass nach Installation von Python 3 nach Python 2 nicht ploetzlich installierte Skripte kaputt sind, weil der Pfad veraendert wird?
Am Ende ist das eine Abwaegungssache, ich bin da selbst gar nicht zwingend fuer das eine oder ander (ich vermeide Windows eh, wo's geht und aergere mich demensprechend ueber eine Menge Idiosynkratien), aber es ist definitiv eine *bewusste* Entscheidung, den Pfad nicht anzufassen.
Was im uebrigen auch unter UNIX eigentlich nix und niemand tut - da wird halt stattdessen in ein Standardverzeichnis ein Link oder Executable gepackt, etwas, dass es so unter Windows nicht so richtig gibt. Denn wenn alle Programme zB in "Program Files" installieren, dann ist da ziemlich Muellhalde...
Diez
Auch unter Windows kann man virtualenv benutzen. Dann muss man für das installieren halt den vollen Pfad von python angeben, und für virtualenv auch, danach hat man aber eine isollierte Installation mit gesetzter Umgebungsvariable. Ist meiner Erfahrung nach sinnvoll, wenn man von der Kommandozeile aus arbeitet, aber das war ja auch das Ziel, oder ?
Gruß,
Uwe
python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 29.10.2013 um 00:00 schrieb Uwe Schmitt uschmitt@mineway.de:
Auch unter Windows kann man virtualenv benutzen. Dann muss man für das installieren halt den vollen Pfad von python angeben, und für virtualenv auch, danach hat man aber eine isollierte Installation mit gesetzter Umgebungsvariable. Ist meiner Erfahrung nach sinnvoll, wenn man von der Kommandozeile aus arbeitet, aber das war ja auch das Ziel, oder ?
Gruß,
Uwe
python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Also virtualenv unter Windows auf dieser pseudoshell ist alles andere als komfortabel. Und von wirklich arbeiten kann in der Kommandozeile auch nicht die Rede sein. Also unter Windows würde ich immer IDLE vor der Shell bevorzugen. Diese wird auch für jede Version installiert und ist ganz bequem, wie unter Windows üblich, aus dem Startmenu heraus zu erreichen. Alles andere macht in meinen Augen keinen Sinn und frustriert nur.
Gruß Steffen
Am 29.10.2013 06:55, schrieb Steffen Frömer (GNS Systems):
Also virtualenv unter Windows auf dieser pseudoshell ist alles andere als komfortabel. Und von wirklich arbeiten kann in der Kommandozeile auch nicht die Rede sein. Also unter Windows würde ich immer IDLE vor der Shell bevorzugen. Diese wird auch für jede Version installiert und ist ganz bequem, wie unter Windows üblich, aus dem Startmenu heraus zu erreichen. Alles andere macht in meinen Augen keinen Sinn und frustriert nur.
Gruß Steffen _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Ja, das sehen ich auch so, daher benutze ich cygwin oder msys, dann kann man auch ein Windows-Sytem bequem "handhaben" :)
Gruß, Uwe.
Am 28.10.2013 22:12, schrieb Johannes Findeisen:
Umpf, Du moechtest aber doch sicher, dass dein Terminal unter Windows die Python Binary findet wenn Du "python" tippst, oder nicht? Wie soll das denn anders funktionieren?
Oder hab ich dich jetzt komplett falsch verstanden?
Tja, aber welches Python soll rauskommen, wenn du "python" eingibst? 2.4, 2.5, 2.6, 2.7, 3.2, 3.3? X86 oder AMD64 binaries? Hinzu kommt, dass Windows PATH auch bei der Suche nach DLLs verwendet. Das Problem ist alles andere als trivial.
On Mon, 28 Oct 2013 22:28:13 +0100 Christian Heimes wrote:
Am 28.10.2013 22:12, schrieb Johannes Findeisen:
Umpf, Du moechtest aber doch sicher, dass dein Terminal unter Windows die Python Binary findet wenn Du "python" tippst, oder nicht? Wie soll das denn anders funktionieren?
Oder hab ich dich jetzt komplett falsch verstanden?
Tja, aber welches Python soll rauskommen, wenn du "python" eingibst? 2.4, 2.5, 2.6, 2.7, 3.2, 3.3? X86 oder AMD64 binaries? Hinzu kommt, dass Windows PATH auch bei der Suche nach DLLs verwendet. Das Problem ist alles andere als trivial.
Interessant! Unter Linux etc. hab ich natuerlich genau das gleiche Problem. "python" kann ja nur einem Python zugeordnet sein. Ich habe mich halt fuer Python 2.7.* entschieden aber eben die Moeglichkeit "python3" zu tippen und dann hab ich halt Python3. Und Du hast vollkommen Recht, trivial ist das Problem nicht.
Ich denke allerdings wenn sich jemand Python zum Programmieren installiert ist es unter Windows auf jeden Fall praktisch den $PATH zu erweitern. Dennoch sollte man das Problem vor Augen haben was passiert wenn man auch ne andere Version installieren moechte.
Johannes
Am 28.10.2013 22:28, schrieb Christian Heimes:
Tja, aber welches Python soll rauskommen, wenn du "python" eingibst? 2.4, 2.5, 2.6, 2.7, 3.2, 3.3? X86 oder AMD64 binaries?
Ganz einfach: Das erste in $PATH. Verzeihung, ich meine natürlich in %PATH%.
Hinzu kommt, dass Windows PATH auch bei der Suche nach DLLs verwendet.
Das ist eine der schlimmsten Design-Schwächen von Windows.
On Mon, 28 Oct 2013 22:12:00 +0100 Johannes Findeisen mailman@hanez.org wrote:
On Mon, 28 Oct 2013 21:58:45 +0100 Marek Kubica wrote:
On Mon, 28 Oct 2013 22:56:18 +0200 "Diez B. Roggisch" deets@web.de wrote:
Ich denke mal, er mein PATH. Und ja, das ist ein Feature. Kann man drueber debattieren, aber ein Bug ist es nicht.
Dafür hat der Installer wenn ich mich richtig erinnere eine Einstellung, den Installationspfad in PATH einzutragen. Ob das auf Windows ein sinnvolles vorgehen ist, sei mal dahingestellt.
Umpf, Du moechtest aber doch sicher, dass dein Terminal unter Windows die Python Binary findet wenn Du "python" tippst, oder nicht? Wie soll das denn anders funktionieren?
Oder hab ich dich jetzt komplett falsch verstanden?
Unter Windows ist das eh nicht so üblich Sachen in den PATH zu tun, macht eigentlich keine Applikation. Ist natürlich für Shell-User etwas unpraktisch.
Wenn ich mich richtig erinnere (ist schon einige Zeit her) registriert der Installer eh .py auf den Python-Interpreter, so dass man via skriptname.py die Datei aufrufen kann.
Grüße, Marek
participants (8)
-
"Steffen Frömer (GNS Systems)" -
Alexander Langer -
Christian Heimes -
Diez B. Roggisch -
Hartmut Goebel -
Johannes Findeisen -
Marek Kubica -
Uwe Schmitt