On May 19, 2014, at 7:48 PM, Daniel Holth <[email protected]> wrote: > On Mon, May 19, 2014 at 7:40 PM, Nick Coghlan <[email protected]> wrote: >> >> On 20 May 2014 01:38, "Donald Stufft" <[email protected]> wrote: >>> >>> If we do standardize we should also likely standardize on how we handle >>> alternative interpreters. Things like PyPy, Jython etc. >> >> The idea of a "py" launcher equivalent for POSIX systems likely has a place >> in that discussion. >> >> As far as the original post goes, the main place where I believe this is >> currently a common issue is on POSIX systems with parallel Python 2 & 3 >> stacks. >> >> On Windows, there is only "python", and PATH controls which version you get. >> You use the "py" command line options to nominate a specific interpreter. >> >> On POSIX, there is generally "python", "python2", "python2.x", "python3" and >> "python3.y", with "python" referring to the default Python 2 install (except >> on Arch). CPython provided scripts that exist in both (like pydoc) have a >> similar naming scheme, while Python 3 only scripts (like pyvenv) omit the >> Python 2 variants, and the unqualified names refer to the Python 3 version. >> >> At least pip 1.5+ follows the same naming conventions (I'm not sure about >> earlier versions). >> >> So, I think there are two problems here: >> >> 1. The dual Python 2/3 stacks that are common on POSIX systems >> 2. The more general problem of installing packages for multiple Python >> interpreters without naming conflicts in POSIX binary directories >> >> I think we actually solved problem 1 pretty well when implementing ensurepip >> - the current UI for enabling it is a horrible internal-only hack, but the >> *behaviour* available when pip is installing itself under ensurepip is >> exactly what I would like to see standardised on that front (the >> python.commands extension in PEP 459 already distinguishes between entry >> points with wrappers to be generated at install time and pre-built scripts). >> >> For the more general case, I don't believe we even have a behavioural >> precedent to consider following at this point. >> >> Cheers, >> Nick. > > I think of the problem as having two classes of programs: programs > that help you use Python itself (pip, ipython), and applications that > are useful on their own (Mercurial). Only the first kind should have > the Python version suffix. I find the second kind very interesting, > mature applications for which the implementation language is not a > nuisance for the user.
I agree with these two classifications, however I'm also not sure if it actually matters or if something like Mercurial could just get the versioned suffixes and 99% of people just ignore them. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
