[Trent]
In any case, I'd say it is extremely *common* for Windows users to put the Python install dir on their PATH -- just as it is common for Windows Perl and Ruby users to put the interpreter dir on their PATH. I'd then say that the obvious place to put user scripts installed via distutils is that same directory.
[Thomas Heller wrote]
Well, I don't think so. It *may* be common for windows users who use the command line ;-), but I would guess that's a minority anyway.
A minority of Windows users of Python use the command line? Really? Anyone coming from Unix will immediately go there. Last I remember "Learning Python" and the Python tutorial and other intro texts encourage the user to open the interactive shell at the command line to play around. You may be right, though. Even if it is "a minority" I suspect that is still a big number. Even for that set of Windows users that *do* use the command line, having Python get on their PATH automatically just makes sense: It allows other systems that depend on Python to be able to just work after an installation. For example, the Mozilla build system on Windows requires an installation of Perl. The build instructions can just say "install ActivePerl" (which puts Perl on the user's PATH) and thereafter the build system can easily find the Perl is needs. I bet that systems out there requiring Python have more difficulty. It allows tutorials/introductory-texts to have a lowest common denominator that just works for newbies on all platforms: 1. install Python 2. type "python script.py" Then they can get on to all the subtle platform-specific bells and whistles, viz:
Even though I *use* the command line, I've never put python.exe on my PATH. It's easier to type 'myscript' or 'myscript.py' than 'python myscript.py' anyway.
That is presuming that the Windows installer set up a .py file association and put .py;.pyc;... in the PATHEXT env. var. Does putting an installed Python on the PATH cause damage in any way?
Then, I have multiple versions installed on my machine, and to select between 2.3.5, 2.4.1, and the CVS version I can always use 'py23 myscript.py', 'py24 myscript.py', 'py myscript.py' and 'py_d myscript.py' - the latter to run it with the debug compiled CVS version. I had created batchfiles py23.bat and so on which specify the directory of the python.exe or python_d.exe files.
A week or so ago I asked you what you thought of the idea of having the Windows build (and installers) have a "pythonXY.exe" or "pythonX.Y.exe" along with the usual "python.exe". This would match what is done on other platforms to allow multiple versions on Python on the PATH and still be able pick a specific one. (I'm not sure if you replied.) I do something similar to your "py23", "py24", ... thing. A common mechanism for this would be nice.
And this also explains why I'm still waiting for the extented version of the '-m' command line option and did not bother to put the PythonXY\Scripts directory on the PATH - I would loose the ability to easily switch versions.
And gain a subtle python-specific way to launch a script. I realize I am ranting above, but I just think it is crazy to have the situation these days where, for example, I download and install pychecker and then try to run it: C:\trentm\tmp>pychecker 'pychecker' is not recognized as an internal or external command, operable program or batch file. I understand your wanting a mechanism to easily be able to run any Python scripts/modules you have with any Python installation/build you have, but the common user case is just: (1) I have my latest Python installation, (2) I want to run something installed with "python setup.py install" Trent -- Trent Mick TrentM@ActiveState.com