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<mhamm...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
