Context: migrating Python 2 app to Python 3
In the docs here: https://docs.python.org/3/howto/pyporting.html
They mention:
Once your dependencies are no longer blocking you, use continuous integration to make sure you stay compatible with Python 2 & 3 (tox can help test against multiple versions of Python; pip install tox)
If you are no longer blocked by your source code nor your dependencies to fully transition to Python 3, why would you continue to also support Python 2?
Is that only a consideration for when you might have users on both Python 2 and Python 3?
If nothing imports my Python app, then there's no risk in fully migrating to Python 3 and dropping Python 2 support, correct?
If you are no longer blocked by your source code nor your dependencies to fully transition to Python 3, why would you continue to also support Python 2?
Nowadays you would probably not bother supporting Python 2 in a stand-alone app, but when that document was written, Python 2 was the norm, so supporting both versions was essential for widely used applications and libraries.
Is that only a consideration for when you might have users on both Python 2 and Python 3?
Yes
If nothing imports my Python app, then there's no risk in fully migrating to Python 3 and dropping Python 2 support, correct?
It depends on the user base that your app targets. You can expect most personal / consumer users to have Python 3 on their machines, or to be able to install it if it is not present or not the default Python (though note installing Python 3 may non-trivial for non-technical users).
Commercial or institutional users may be required to use operating systems that don't have Python 3 installed, and may not have the rights to install Python 3 themselves. In this case you would need to support Python 2 until these organisations upgrade to a suitable OS version.
You missed that the document starts with the assumption you want to support both:
With Python 3 being the future of Python while Python 2 is still in active use, it is good to have your project available for both major releases of Python. This guide is meant to help you figure out how best to support both Python 2 & 3 simultaneously.
That's the premise of the document, and it is only natural that it then tells you how to keep your code compatible. Yes, the Python core team will end support entirely in a a short few months time, but that doesn't mean that this document was written with that in mind.
You can use the document to port to Python 3, and then drop Python 2 support entirely, yes, that's fine too.
Yeah I think they are still supporting that keeping legacy Python 2 code in mind.
python 2 will be left not updated very soon so it's better to consider shifting to 3
This topic is particularly germane if you have developed code for the Python Package Index (PyPI) in Python 2 and are porting it to support both Python 2 and Python 3. You will have a "customer base" for both versions for at least the short foreseeable future.
Related
How to use python 2 packages in python 3 project?
I have a Python 3 project, but I need some packages which are written in Python 2.
I do not want to rewrite these python-2 packages, so forking / 2to3 is not an option.
A lot of the previous questions concern using Python 2 modules in Python 3 projects. Here's the most complete explanation. It also works the other way around and suggests the following alternatives:
Using the subprocess module for requests and getting the response through the CLI. So far the most straightforward way to make cross-references.
python-fire can quickly add a CLI to a Python 3 library. You'll have a reasonable API to call from the Python 2 project.
3to2. This utility converts Python 3 code to Python 2. It remains unclear how it handles complex Python 3 projects with dependencies and Python 3-only features.
six and __future__. It seems both of these modules are intended for writing the code compatible with Python 2-3, not for using Python 3 libraries in Python 2 projects.
You can't. Any module you import in py3 codebase needs to be py3 compatible. If you can't make the upstream project do it for you, you'll have to do it yourself. As mentioned in the comments, 2to3 utility should help you with that.
I've dabbled a little bit in Python - not much beyond modifying other people's scripts. Now I'm considering getting into it for real, and have hit the "Choose whether to learn 3.x or 2.x" dilemma. I've read that the main issue with 3.x is the existence of a lot of legacy 2.x code which won't run with 3.x ... but that was a while ago. Is it still the case that backwards-incompatibility is an important consideration against working in Python 3.x?
Note: A similar question was asked 5 years ago:
Is it still too early to hop aboard the Python 3 train?
In my experience, there's only a handful of libraries that are needed for using Python in the real world, and all the major ones have been ported for years and years. Most of the Python 2 only libraries are ones that have become stagnant and are no longer updated (there are probably exceptions, but none that I'm aware of).
The real question, though, is are there any libraries that you need that are Python 2.7 only? If the answer is "No" or "I don't know" then I would definitely suggest starting on Python 3.
Another factor is that it's usually quite easy to take Python 3 code and change it to run on Python 2 (if the need arises), since Python 2.7 has a lot of forwards compatible features. The reverse, taking Python 2 code and porting it to Python 3, is not nearly so clean.
As said in python official documentation
Python 2.x is legacy, Python 3.x is the present and future of the language
And you can check this web app here (or this as #Peque suggests) for python3 library support.
Yes, I know about IronPython 3 compatibility, but that is from two years ago. I was searching on the internet but couldn't find any information on this that is up-to-date.
So does IronPython support Python 3? If not, how many of the future imports work, and are there any Iron-specific ways to make it seem more like Python 3?
Currently it doesn't support Python3. IronPython3 Todo. All future imports supported by the standard Python 2.7 interpreter should be supported by the newest version of IronPython.
And there are no Iron-specific ways to make it seem more like Python3 as far as I know.
IronPython 3 is once again alive. An alpha for Python 3.4 was released in April 2021. It is a very active effort which is being supported by the .NET Foundation. More here: Python 3.4 Release Notes
You can use ExaScript, a fork of the IN-DEVELOPMENT IronPython 3, providing standard Python libraries along with multiple specialty libraries, such as PowerCrypt4, a cryptography library, OmniBeanLib, a library containing lots of common functions, and OmniBeanEB, a rewrite of the Small Basic Library that provides almost every function necessary to build a good GUI/Console application.
Best of all, for making Windows Forms applications, use EPFramework, an included library to generate a fresh, reactive, modern UI for your project.
I am just learning python on my ubuntu 8.04 machine which comes with
python 2.5 install. Is 2.5 too dated to continue learning? How much
of 2.5 version is still valid python code in the newer version?
Basically, python code, for the moment, will be divided into python 2.X code and python 3 code. Python 3 breaks many changes in the interest of cleaning up the language. The majority of code and libraries are written for 2.X in mind. It is probably best to learn one, and know what is different with the other. On an ubuntu machine, the python3 package will install Python 3, which can be run with the command python3, at least on my 8.10 install.
To answer your question, learning with 2.5 is fine, just keep in mind that 3 is a significant change, and learn the changes - ask yourself as you code, "how would this be different in 3, if at all?".
(As an aside, I do wish Ubuntu would upgrade to 2.6 though. It has a nice compatibility mode which tries and points out potential difficulties. But python is in such big use on a modern Linux distro, it can be a difficult change to make)
Here's an article describing 2.6 -> 3's changes
Python 2.5 will be fine for learning purposes. In the interest of learning you will probably want to look into the differences that python 3.0 has introduced, but I think most of the Python community is still using Python 2, as the majority of libraries haven't been ported over yet.
If your interested in 2.6 here is a blog post on compiling it on Hardy, there may even be a package for it somewhere out there on the internets.
Follow up, if there is a package I'm not finding it. Self compiling is pretty simple for most things, though I've never tried to compile Python.
I don't think it is 'too dated' to use, but there are some really nice features in python 2.6 that make it worth the update. This article will give you the details. As long as you have control of the machine, it is worth it.
I don't have any statistics but my impression is that Python 2.5 is the version most in use today. It is certainly not "dated" - I still use Python 2.5 and I expect that I will be using it for weeks or months yet to come.
If you have Python 2.6 available, though, I would suggest upgrading, as it's still fairly similar to Python 2.5 but will put you in better position for using Python 3.
Also, right now the 2.x branch is the most supported one, so I would also say that it's a good reason to start with that version.
And when the moment comes, you can always switch to Python 3.
Python 2.5 is fine. There are still plenty of people on Python 2.4 and 2.3.
One thing to keep in mind about python 2.6 is that some libraries may not work. Numpy comes to mind..
If I was going to start an open source project using Python what version should I use to ensure that the vast majority of users can use it on their system?
I'm the kind of person who quickly jumps to the next version (which I'll do when Python 3 comes out) but many people may be more conservative if their current version seems to be working fine. What version would hit the sweet spot but still allow me to enjoy the newest and coolest language enhancements?
As python is in kind of an transition phase towards python 3 with breaking backward compatibility I don't think it is a good idea to go python 3 only. Based on the time line there will be at least one or two following releases of the 2.x series after 2.6/3.0 in october.
Beside not having python 3 available on your target platforms, it will take some time until important external python libraries will be ported and usable on python 3.
So as Matthew suggests staying at 2.4/2.5 and keeping the transition plan to python 3 in mind is a solid choice.
I've not seen a system with less than 2.3 installed for some time. Mostly 2.4+ is installed by default for most OS I use now. 2.3 is just on an older Solaris machine. Linux distros tend to have 2.4+, as does OS X.
IIRC, 2.4 has a lot of the features 2.5 does, but usable only with
from __future__ import *
You can use different versions of python on each machine.
Coding something new, I would not use anything less than python2.5. You can do apt-get install python2.5 on stock debian stable.
For windows, don't really worry about it. It's very easy to install the python2.5 msi.
If the users can't be bothered to do that, you can deploy an executable with py2exe (so simple) and build an installer with inno setup (again simple) then it will behave like a standard windows application and will use its own python dlls, so no need to have python installed.
Like Peter said: keep in mind the transition to 3.0 but don't build on it yet.
Python 2.3, or 2.2 if you can live without the many modules that were added (e.g. datetime, csv, logging, optparse, zipimport), aren't using SSL, and are willing to add boilerplate for True/False.
2.4 added decorators. generator expressions, reversed(), sorted(), and the subprocess and decimal modules. Although these are all nice, it's easy to write Pythonic code without them (assuming that your project wouldn't make heavy use of them).
2.5 added with, relative imports, better 64 bit support, and quite a bit of speed. You could live without all of those easily enough.
2.6 isn't released (although it's very close), so while it might appeal to developers, it doesn't have the compatibility you're after.
Take a look at the release notes for 2.3, 2.4, 2.5, and the upcoming 2.6 (use http://www.python.org/download/releases/2.Y/highlights/ where 'Y' is the minor version).
FWIW, for SpamBayes we support 2.2 and above (2.2 requires installing the email package separately). This isn't overly taxing, but the 2.3 additions are useful enough and 2.3 old enough that we'll probably drop 2.2 before long.
If the project is going to be mainstream and will be run on Linux the only sensible choise is 2.4 - just because it is a pain to get anything else installed as default on Enterprise Linuxes.
In any case, any modern OS will/can have 2.4 or newer.
You should use Python 2.7, the final major version of Python 2.
Python 3.x currently has limited 3rd-party library support, and is often not installed by default. So you are looking at the 2.x series.
Python 2.7 is essentially fully backwards-compatible with earlier 2.xs. In addition, it can give deprecation warnings about things that won't work in Python 3. (Particularly, it will pay to maintain unit tests, and to be pedantic about Unicode- vs. byte-strings.) The warnings will force you to write good code that the automated 2to3 tool will be able to translate to Python 3.
Guido van Rossum officially recommends maintaining a single Python 2 code-base, and using 2to3 together with unit testing to produce compatible releases for Python 2 and 3. (Since PEP 3000 was written, Python 2.6 has been superseded by 2.7.)