Hi Nick,
On 04.11.2017 16:01, Nick Coghlan wrote:
On 5 November 2017 at 00:40, Wolfgang <tds...@mailbox.org> wrote:
On 04.11.2017 14:29, Antoine Pitrou wrote:
Hello Wolfgang,
On Sat, 4 Nov 2017 12:25:57 +0100 (CET)
tds...@mailbox.org wrote:
Hello,
one of my long standing ideas to improve Python is to adjust the
release cycle and version number handling. In short, to simplify it.
There has been ample discussion in the past about changing our release
cycle one way or another. In short, the meta-problem is there are many
contradicting interests which would each favour a different solution to
the problem. See for example this PEP (ultimately rejected):
https://www.python.org/dev/peps/pep-0407/
and the discussion that ensued:
https://mail.python.org/pipermail/python-dev/2012-January/thread.html#115591
I haven't read your proposal in detail, but I suspect that it may be
vulnerable to some of the same objections. The big objection being
that a significant part of our ecosystem (that is, to put it roughly,
the more corporate-minded segment, though I believe it is a
simplification and may include other segments, such as Debian stable
users and maintainers) doesn't want to deal more frequent feature
releases.
I read this PEP and some of the discussion.
The difference to my idea is not to propose a LTS version and feature
preview releases.
The simplest form of my change is to switch from today major.minor to simply
major for the feature release cycle.
We're currently more likely to go the other direction, and stick with
the 3.x numbering for an extended period (potentially reaching 3.10,
3.11, 3.12, etc), so that the ongoing disruption caused by the 2.x ->
3.x transition has had a chance to settle down before we ask anyone to
start calling anything "Python 4".
A good point but two digits minor version numbers have the possibility
to break a lot code. There is a lot of stuff out where a single digit
major version is assumed. Even the official Python build for windows
with python27.dll, python36.dll can be problematic because the dot
is omitted between numbers.
Other do the same for compilation they concatenate only majorminor for a
name.
Then version 3.10 is the same as 31.0.
Ok I know this will take a while.
But for the first 2.7.10 version even there some other library code
was broken because of such assumptions.
While the problems Linux distros are facing with whether "python"
should refer to "python2" or "python3" are at least arguably
self-inflicted (especially for those that already dealt with the
Python 1.5.2 -> Python 2.0 migration back in the early 2000s), nobody
is really looking forward to having to figure out how to adjust to a
potential future Python 4.0 that invalidates all the current "python3"
based naming schemes that have been introduced to work around the fact
that Python 3.x needed to be parallel installable with Python 2.x
without breaking any existing Python 2.x applications. We're not even
sure yet when we're going to update PEP 394 to say that we think it's
reasonable for distros to start using "python" to mean "python3" (see
https://www.python.org/dev/peps/pep-0394/ and
https://github.com/python/redistributor-guide/issues/1 for more
discussion on the latter point).
I know on some build computers I have the same problem.
But solved it for my scripts by using the major number as compatibility
specifier and it works fine for me.
Also knowing it is not upward compatible.
The whole problem can only be solved by something used for Windows
where the Python launcher deals with this. A Python launcher (py) for
Linux can solve this there. Allowing also distributions to configure a
fall back.
For example the user specified python3 but I know it will be compatible
with python4 so the launcher can do something like
python3 is not found then I use python4 if available.
ex.:
#!/usr/bin/env py -3
And handle it as configurable version hint. Or even allowing alternative
implementation like pypy if compatible.
Regards,
Wolfgang
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
