Servus, On Mon, 28 Oct 2013 15:59:20 +0100 Alexander Langer 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 Mon, 28 Oct 2013 22:56:18 +0200 "Diez B. Roggisch" 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 Oct 28, 2013, at 11:12 PM, Johannes Findeisen 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" 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 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.

Siehe http://www.python.org/dev/peps/pep-0397/

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 29.10.2013 um 00:00 schrieb Uwe Schmitt :

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. -- Dr. rer. nat. Uwe Schmitt Leitung F/E Mathematik mineway GmbH Gebäude 4 Im Helmerswald 2 66121 Saarbrücken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt@mineway.de www.mineway.de Geschäftsführung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbrücken HRB 12339