On 2019-02-13, Terry Reedy wrote: > It appears python is already python3 for a large majority of human users (as > opposed to machines).
IMHO, the question about where /usr/bin/python points is more important for machines than for humans. Think about changing /bin/sh to some different version of the Borne Shell that changes 'echo'. Or changing 'awk' to some incompatible version. That's going to break a lot of scripts (cron jobs, etc). I experienced the bad old days when you couldn't rely on /bin/sh to be a proper POSIX shell. It was a mess and it wasted countless hours of human life to work around all the flavours. Python is not as fundamental as the Unix shell but it has replaced a lot of shell scripting. How can we avoid making a lot of work for people? I don't see an easy answer. We don't want Python to become frozen forever (whether it is called 'python', 'python3', or 'py'). OTOH, making /usr/bin/python point to the most recent X.Y release doesn't seem like a good solution either. For example, if I used 'async' as a variable in some of my scripts and then 3.7 broke them. Should we dust off PEP 407 "New release cycle and introducing long-term support versions"? Having /usr/bin/python point to a LTS release seems better to me. I don't know if the core developers are willing to support PEP 407 though. Maybe OS packagers like Red Hat and Debian will already do something like LTS releases and core developers don't need to. /usr/bin/python in Red Hat has behaved like that, as far as I know. Another idea is that we could adopt something like the Rust "language edition" system. Obviously lots of details to be worked out. If we had that, the 'py' command could take an argument to specify the Python edition. OTOH, perhaps deprecation warnings and __future__ achieves most of the same benefits. Maintaining different editions sounds like a lot of work. More work than doing LTS releases. Maybe the solution is just that we become a lot more careful about making incompatible changes. To me, that would seem to reduce the rate that Python is improving. However, a less evolved but more stable Python could actually have a higher value to society. We could create an experimental branch of Python, e.g. python-ng. Then, all the crazy new ideas go in there. Only after they are stable would we merge them into the stable version of Python. I'm not sure how well that works in practice though. That's similar to what Linux did with the even/odd version numbering. It turned into a mess because the experimental (next) version quickly outran the stable version and merging fixes between them was difficult. They abandoned that and now use something like PEP 407 for LTS releases. Regards, Neil _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
