Hi, I’ve read the latest version of this PEP, as updated by Nick Coghlan in the Mercurial repo on July, 20th. Excuse me if I repeat old arguments, I did not reread all the threads.
In summary, I don’t think the PEP is useful right now, nor that it will set a good practice for the future. > * Unix-like software distributions (including systems like Mac OS X and Minor: I call these “operating systems”. > * The Python 2.x ``idle``, ``pydoc``, and ``python-config`` commands should > likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``, > with the original commands invoking these versions by default, but possibly > invoking the Python 3.x versions instead if configured to do so by the > system administrator. This item ignores that on some OSes, defining the default Python version is not a decision made by the sysadmin. The example I know is Debian (and derivatives): despite what one can read on the Web, it is not a good idea to change /usr/bin/python to point to the version you want; the decision affects all scripts used by the system itself, and is thus the call of the Debian Python maintainers. (FTR, Debian developers discussed adding /usr/bin/python2 at the latest DebConf and rejected it; I don’t know if the arguments raised are the same as mine, but maybe Piotr or someone else will chime in in this thread.) > This is needed as, even though the majority of distributions still alias the > ``python`` command to Python 2, some now alias it to Python 3. Some of > the former also do not provide a ``python2`` command; hence, there is > currently no way for Python 2 code (or any code that invokes the Python 2 > interpreter directly rather than via ``sys.executable``) to reliably run on > all Unix-like systems without modification, as the ``python`` command will > invoke the wrong interpreter version on some systems, and the ``python2`` > command will fail completely on others. The recommendations in this PEP > provide a very simple mechanism to restore cross-platform support, with > minimal additional work required on the part of distribution maintainers. I would like more data about this. How many OSes have moved their python executable to python2? How much people does that impact? Right now I think that there’s only Arch and Gentoo, which I would call minority platforms. (I’m aware that all UNIX-like free operating systems could be considered a minority OS all together, but we’re talking about UNIX-like OSes here :) Doing what the majority does is not always a good thing, but for this PEP I think that numbers can help us assess whether the trouble/benefit ratio is worth it. In my opinion, the current situation is clear: python is some python2.y, python3 is a python3.y, this is not ambiguous and will still work in ten years when we get python4. Thus, the previous decision of python-dev to use python3 indefinitely seems good to me. As a script/program author, if I use python2 in my shebangs now to support what appears to be minority platforms, I’m breaking compatibility with a huge number of systems. Therefore, I don’t see how this PEP makes the situation better. If one OS wants to change the meaning of the python command, then its packaging tools should adapt shebangs, and its users should be aware that the majority of existing Python 3 scripts will break. Therefore, I’m strongly -1 on this PEP: changing the meaning of python brings much trouble for little or no benefit, and adding python2 adds another compatibility trouble. It would be interesting to have feedback from people who lived the transition to Python 2. > * The ``pythonX.X`` (e.g. ``python2.6``) commands exist on some systems, on > which they invoke specific minor versions of the Python interpreter. It > can be useful for distribution-specific packages to take advantage of these > utilities if they exist, since it will prevent code breakage if the default > minor version of a given major version is changed. However, scripts > intending to be cross-platform should not rely on the presence of these > utilities, but rather should be tested on several recent minor versions of > the target major version, compensating, if necessary, for the small > differences that exist between minor versions. This prevents the need for > sysadmins to install many very similar versions of the interpreter. Here again I would be interested in more numbers. Pythons that people manually download and install using the provided makefile do have these pythonx.y executables, so I thought that all OSes did likewise. Moreover, I disagree about the implied assertion that the minor number hardly matters (I’m paraphrasing): Python 2.6 and 2.7 *are* different, not “very similar”. I don’t know very well the usages of the community, but in my experience moving from 2.x to 2.x+1, or even just checking that your code still works, is a Big Deal. I’d like this whole bullet item to be removed. > Impact on PYTHON* Environment Variables I think this section should be named PYTHONPATH, as it is the only envvar that it talks about. Another minor edit: s/folder/directory/ Regards _______________________________________________ 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
