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.
Related
I've read in few places that generally, Python doesn't provide backward compatibility, which means that any newer version of Python may break code that worked fine for earlier versions. If so, what is my way as a developer to know what versions of Python can execute my code successfully? Is there any set of rules/guarantees regarding this? Or should I just tell my users: Just run this with Python 3.8 (for example) - no more no less...?
99% of the time, if it works on Python 3.x, it'll work on 3.y where y >= x. Enabling warnings when running your code on the older version should pop DeprecationWarnings when you use a feature that's deprecated (and therefore likely to change/be removed in later Python versions). Aside from that, you can read the What's New docs for each version between the known good version and the later versions, in particular the Deprecated and Removed sections of each.
Beyond that, the only solution is good unit and component tests (you are using those, right? 😉) that you rerun on newer releases to verify stuff still works & behavior doesn't change.
According to PEP387, section "Making Incompatible Changes", before incompatible changes are made, a deprecation warning should appear in at least two minor Python versions of the same major version, or one minor version in an older major version. After that, it's a free game, in principle. This made me cringe with regards to safety. Who knows if people run airplanes on Python and if they don't always read the python-dev list. So if you have something that passes 100% coverage unit tests without deprecation warnings, your code should be safe for the next two minor releases.
You can avoid this issue and many others by containerizing your deployments.
tox is great for running unit tests against multiple Python versions. That’s useful for at least 2 major cases:
You want to ensure compatibility for a certain set of Python versions, say 3.7+, and to be told if you make any breaking changes.
You don’t really know what versions your code supports, but want to establish a baseline of supported versions for future work.
I don’t use it for internal projects where I can control over the environment where my code will be running. It’s lovely for people publishing apps or libraries to PyPI, though.
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
I'm looking at some software that is wanting to bring in Python 3.6 for use in an environment where 3.5 is the standard. Reading up on Python's documentation I can't find anything about whether:
3.5 is representative of a semantic version number
3.6 would represent a forwards compatible upgrade (ie: code written for a 3.5 runtime is guaranteed to work in a 3.6 runtime)
The fact that this page about porting to 3.7 exists makes me think strongly no but I can't see official docs on what the version numbers mean (if anything, ala Linux kernel versioning)
In the more general sense - is there a PEP around compatibility standards within the 3.X release stream?
The short answer is "No", the long answer is "They strive for something close to it".
As a rule, micro versions match semantic versioning rules; they're not supposed to break anything or add features, just fix bugs. This isn't always the case (e.g. 3.5.1 broke vars() on a namedtuple, because it caused a bug that was worse than the break when it came up), but it's very rare for code (especially Python level stuff, as opposed to C extensions) to break across a micro boundary.
Minor versions mostly "add features", but they will also make backwards incompatible changes with prior warning. For example, async and await became keywords in Python 3.7, which meant code using them as variable names broke, but with warnings enabled, you would have seen a DeprecationWarning in 3.6. Many syntax changes are initially introduced as optional imports from the special __future__ module, with documented timelines for becoming the default behavior.
None of the changes made in minor releases are broad changes; I doubt any individual deprecation or syntax change has affected even 1% of existing source code, but it does happen. If you've got a hundred third party dependencies, and you're jumping a minor version or two, there is a non-trivial chance that one of them will be broken by the change (example: pika prior to 0.12 used async as a variable name, and broke on Python 3.7; they released new versions that fixed the bug, but of course, moving from 0.11 and lower to 0.12 and higher changed their own API in ways that might break your code).
Major versions are roughly as you'd expect; backwards incompatible changes are expected/allowed (though they're generally not made frivolously; the bigger the change, the bigger the benefit).
Point is, it's close to semantic versioning, but in the interests of not having major releases every few years, while also not letting the language stagnate due to strict compatibility constraints, minor releases are allowed to break small amounts of existing code as long as there is warning (typically in the form of actual warnings from code using deprecated behavior, notes on the What's New documentation, and sometimes __future__ support to ease the migration path).
This is all officially documented (with slightly less detail) in their Development Cycle documentation:
To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.
new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
new minor versions are feature releases; they get released annually, from the current in-development branch;
new micro versions are bugfix releases; they get released roughly every 2 months; they are prepared in maintenance branches.
Here's the document on updating to 3.6.
If you had, for example, open(apath, 'U+') in your code in 3.5, it would fail in 3.6. So, clearly, Python 3.6 is not entirely backwards compatible to every usage in 3.5.
Realistically, you will need to test, although I feel fairly comfortable telling the average stackoverflow reader from almost every area that they should feel comfortable doing this upgrade.
As for Semantic Versioning, specifically, Python does not follow it, but it isn't entirely agnostic to the meaning of major, minor and bugfix releases. Python guidelines for its developers can be found here.
To clarify terminology, Python uses a major.minor.micro nomenclature
for production-ready releases. So for Python 3.1.2 final, that is a
major version of 3, a minor version of 1, and a micro version of 2.
new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long
in advance;
new minor versions are feature releases; they get released annually, from the current in-development branch;
new micro versions are bugfix releases; they get released roughly every 2 months; they are prepared in maintenance branches.
Also read PEP440, which is for modules, not about releasing new versions of python itself, but still relevant for the philosophy of the ecosystem.
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.