Does Long-term surppot version and stable version exist in Python 2.x or Python 3.x version? And if so, what are the criteria?
not currently
see PEP407 status: "deferred"
https://www.python.org/dev/peps/pep-0407/
It doesn't use same wording but on 7. November, 2019 PEP602 was accepted which introduced release cycles. You can find more info about current versions and their states here.
Related
I need to install Python 3.8 on a Windows computer and hope to use the latest minor version of 3.8.12. The official release web page provides tarball files of the source code but no Windows installer. Python 3.8.10 provides Windows installers, but it is not the latest version.
I am wondering:
Why v3.8.12 does not provide any Windows installer?
If we want to use v3.8.12, what can we do?
I appreciate your help and suggestions.
https://devguide.python.org/#status-of-python-branches provides a summary of the various release statuses.
features
new features, bugfixes, and security fixes are accepted.
prerelease feature fixes, bugfixes, and security fixes are accepted
for the upcoming feature release.
bugfix bugfixes and security fixes are accepted, new binaries are
still released. (Also called maintenance mode or stable release)
security only security fixes are accepted and no more binaries are
released, but new source-only versions can be released
end-of-life release cycle is frozen; no further changes can be pushed
to it.
Python 3.8 is currently in security mode, so only source releases (and no binary installers) are provided from Python itself.
As the page you linked to says,
According to the release calendar specified in PEP 569, Python 3.8 is now in the "security fixes only" stage of its life cycle: 3.8 branch only accepts security fixes and releases of those are made irregularly in source-only form until October 2024. Python 3.8 isn't receiving regular bug fixes anymore, and binary installers are no longer provided for it. Python 3.8.10 was the last full bugfix release of Python 3.8 with binary installers.
Python 3.8.10 was the last release at the bug fix stage, and so the last for which Python officially provided binary installers. If you want a binary installers for 3.8.12, you'll have to either make one yourself from the source or find someone else who has done it or will do it for you.
You can easily build it by following the instructions.
Add the resulting PCbuild\win32 directory to PATH and you are good to go.
Why was Python 3.7.7 released after Python 3.8.2?
When its the same version, meaning python2 and python3
It says so on the website: https://www.python.org/downloads/
Each minor release (i.e. <major>.<minor>.<patch>) introduces new features and in some cases makes backwards incompatible fixes. That means that someone might need to still stay on 3.7 - but you still might want to fix bugs in the 3.7.x line of releases.
That bug fix release for the 3.7 line can then be released after any release to 3.8 (or any other 3.x release for that matter, if it's something only related to that minor release). In general older minor releases are abandoned after a while, and receive no further patches.
From the release notes for Python 3.7.7:
Python 3.8 is now the latest feature release series of Python 3. Get the latest release of 3.8.x here. We plan to continue to provide bugfix releases for 3.7.x until mid 2020 and security fixes until mid 2023.
Python 3.7.7 is the latest bugfix release of Python 3.7.
There is one more planned release for the 3.7.x branch, 3.7.8. After that only security fixes will be applied until 2023.
3.7.8 candidate 1: 2020-06-15 (expected)
3.7.8 final: 2020-06-27 (expected)
Imagine that you have a farm and a tractor, a plow on it and some workers. You want to improve performance in your farm so you buy a new tractor with new features and a new and better plow. Some workers may like to work with it but some others may prefer the classic one because they simply feel more comfortable using it! So the classic lovers want to get a better and bigger plow. So because you are a kind farmer, you upgrade the classic plow as you have eyes on the new tractor.
Now consider farmers as python language developers, farmers as programmers, tractor as python and plow as python versions.
Hope that was useful. :D
New to python, hence the question...
I am going to be working with python 2.6.6 and I am trying to set up my eclipse on CentOS for the same. While trying to get the pydev version I don't know which version I should get? I see a bunch of them listed for 2.6.x.x and 2.7.x.x. Can I select the latest one in the version series 2.7?
How does this matter with me working with a specific older version of python.
Appreciate the help.
According to http://pydev.org/download.html, the latest version of PyDev supports Python 2.1 or later, no qualifications. So you should be OK with Python 2.6.6 and at least could ask for support if you run into a problem with it.
Sorry to hear your initial experiences with Python have to be with an older version of the interpreter!
At present(May 2013), there are three release versions, all released on may 15
python 3.3.2
python 3.2.5
python 2.7.5
I can understand the need for 2.x and 3.x branches but why are there seperate 3.3.x and 3.2.x versions?
In this link is says The current production versions are 2.7.5 and 3.3.2..
And if you look here it says:
Python 3.2.5 was released on May 15th, 2013. This release fixes a few regressions found in Python 3.2.4, and is planned to be the final 3.2 series bug-fix release.
So you should use 2.7.5 or 3.3.2, but if you need (I don't know why) 3.2.* you have a bug-fixed version.
As wim points out, 3.2.5 is not a current production version, but I assume you're wondering why there were three versions released on 15 May 2013? That is why is the 3.2.x branch still being maintained?
Remember that each 3.n step introduces new features while 3.n.x releases are fixes to existing versions. 3.2.5 is thus a set of bugfixes to 3.2.4 while the 3.3.x branch includes new features not present in 3.2.4. Because new features are, inherently, more likely to introduce new bugs, the maintenance of the older branch allows you a higher stability choice if, for example, you're just putting together a new public release of your webserver and don't want to risk new bugs being introduced by the current branch.
This is a question of python's versioning strategy. Quote from python's wikipedia article:
CPython's public releases come in three types, distinguished by which
part of the version number is incremented:
Backwards-incompatible versions, where code is expected to break
and must be manually ported. The first part of the version number is
incremented. These releases happen infrequently—for example, version
3.0 was released 8 years after 2.0.
Major or "feature" releases, which are largely compatible but introduce new features. The second
part of the version number is incremented. These releases are
scheduled to occur roughly every 18 months, and each major version is
supported by bugfixes for several years after its release.
Bugfix releases, which introduce no new features but fix bugs. The
third and final part of the version number is incremented. These
releases are made whenever a sufficient number of bugs have been fixed
upstream since the last release, or roughly every 3 months. Security
vulnerabilities are also patched in bugfix releases.
So, 3.3 compared to 3.2 introduced new major features, that's why it's in a separate "branch".
Also see:
Python 3.2 Release Schedule
Python 3.3 Release Schedule
Python 3.4 Release Schedule
You should read bit about version numbers. The last digit means, simplified, no new features only bug fixes. So folks who use Python 3.2 can installed a newer revision without changing anything in the behavior of Python.
Is there a known date/timeframe when python 2.7 will not be supported any more in favor of python 3?
As of 13 Apr 2014, from http://hg.python.org/peps/rev/76d43e52d978 (PEP 373, Python 2.7 Release Schedule):
The End Of Life date (EOL, sunset date) for Python 2.7 has been moved
five years into the future, to 2020. This decision was made to
clarify the status of Python 2.7 and relieve worries for those users
who cannot yet migrate to Python 3. See also PEP 466.
In May 2010, Word of God was that patchlevel releases for Python 2.7 will probably be made for at least 6 years.
So, maybe 2016, probably later.
Edit: Pushed back to 2020. See the revision to PEP 373, linked to in other answers.
Recently, that date has been updated to January 1, 2020.
see https://pythonclock.org/
you should read this carefully (ref : https://news.ycombinator.com/item?id=7582300 ):
There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means.
The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.
What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.
Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.
An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.
Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.
So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.
The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.
This article says: “When 2.7 is released, the 2.x line will move into five years of a bug fix-only mode.”
So, as far as I see, Python 2.7 was the last 2.x feature-adding release, and though found bugs are going to be fixed (for some time), new features only go to 3.x releases.
PEP 373 (Python 2.7 Release Schedule) is the official source for the kind of information you asked for.
It currently says "Planned future release dates:"
2.7.7 May 2014
2.7.8 November 2014
2.7.9 May 2015
beyond this date, releases as needed
Also, it says "The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020."
Edited in April 2014, according to http://hg.python.org/peps/rev/76d43e52d978
The Python Developer’s Guide lists the "Status of Python branches" from version 2.6 up to the current version, including their current support status with End-of-life dates.
Currently supported (bug + security fixes):
Python 3.8 (current master/development branch)
Python 3.7
Python 3.6
Python 2.7 (until 2020-01-01)
Security fixes only:
Python 3.5
Python 3.4
Python 2.7 wil be around forever. There is too much old code that uses it that no one wants to rewrite. There is already a fork called Tauthon, but we may see others if this pointless deadline gets real.