On 6/03/2011 12:37 AM, Michael Foord wrote:
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammond<mhammond@skippinet.com.au> wrote:
I think this discussion should be divorced from this PEP and taken up with the discussion about the PATH and the "last installed wins" issue Martin mentions - only all of them taken together will "fix" this issue - not that I personally consider it particularly broken - more like "sub-optimal" :) I updated the draft PEP, explicitly bringing Mac OS X and Cygwin within the scope of the recommendation, and excluding PYTHON* environment variable considerations and Windows-related proposals. The Windows section does include a hit-list that may serve as a useful starting point if someone else felt like starting a Windows specific PEP, though.
The issues are relevant to Windows (there are *other* issues as well but that doesn't mean that the same issue doesn't apply). Guido also said he would like to see Windows addressed.
What issues specifically? If I look at the current PEP language, it refers to "the default version of the Python interpreter" and "all new code that needs to invoke the Python interpreter". Neither of these apply in any meaningful way to Windows. It could be argued that the latter could include .bat files which use Python but that sounds like a theoretical problem (ie, I haven't heard much noise about that) where PEP394 is addressing an observed practical problem. On Windows it seems to be just about 'python2' and 'python3' doing the correct thing in a default command prompt, which while desirable ignores the broader issues (eg, the file associations and anything else "windowsy" and not driven by the command-prompt)
I'll be happy to try and come to some consensus with Martin (and others) on what we *can* do for Windows (as similar to the other platforms as possible would be my goal) and provide appropriate text for the PEP.
IIUC, the PEP language is referring to links which point to a specific version of Python and that there is no suggestion a 'python3' will live in the Python 3 binary tree. If that is correct and assuming we don't want to investigate using links on Windows, I'd suggest the best analogy to the *nix situation could be simply for the installers to generate "python2.bat" and "python3.bat" files and put them in System32 with a "last installed wins" policy. The fact this doesn't help users installing Python "just for me" is fine too from the POV of matching *nix systems - a user installing a private Python build on *nix also doesn't get the python2 and python3 conveniences, nor the automatic PATH convenience. But in practice I expect this would *not* be OK - which just highlights the risks of trying to generalize a specific observed problem on one OS to others. Cheers, Mark