I have an open source project that works fine with python 2 and I am trying to make it work on python 3 as well.
I tried one approach that is using if statements in the code to check sys.version_info.major but this seems to be messy.
Is it possible to specify the interpreter version in setup.py to that when folks use pip install, it automatically pick up a compatible package?
This way, I can branch the code and the packages on github.
so lets say I have
x1.2 for python < 3
x1.1 for python >= 3
if the user has python3, pip should grab x1.1 (not the latest but the latest package for python3)
There is no way for you to specify what version pip should install, no. You can specify Python compatibility in the Trove classifiers, but pip will not differentiate on those, let alone pick a different version based on that.
You are stuck with writing a version that works on both Python 2 and 3. I recommend you read through the Porting Python 2 Code to Python 3 guide and use a compatibility layer support library like six. You can use the Modernize tool to help you rewrite your code here.
You can use 2to3 :
2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code.
and as #Martijn says in comment you can find the best recipe in Porting Python 2 Code to Python 3
Related
I'm working with a software that has an embedded python environment which does not have all of the standard python modules available.
For example there's no pip or pkg_resources. The only way to add 3rd-party modules/packages is by copying them into a path which is referenced in sys.path.
At the moment I am writing the first version of my own package and more will come in the future.
Now to my question. Is it considered a bad approach to have the version number inside the package name or completely as subpackage?
For example mypackage_0_1/ or mypackage/0_1/
If so, what would be a good alternative to solve this problem?
In most of the cases, the version number in a package, regardless of the language, is used to communicate compatibility. For example, Qt: there are Qt4 and Qt5 series. What the numbers mean is that we have different APIs and switching from Qt4 to Qt5 will mostly break your application. Likewise, Python follows this pattern: you have Python 2.x and 3.x series. This means that if you write your application for Python 3.6, it is expected that it will work with Python 3.7. In other words, Python 3.x releases are forward compatible (ie, software written for a older version of Python 3.x is expected to run OK with newer versions). However, writing your application for Python 2.7 and running it in Python 3.7, for example, will mostly bring unexpected results. Hence, Python 3.x breaks the compatibility with Python 2.x and they are neither forward of backward compatible.
So, my advice is to follow this rule: use a version number in the package name only and only if you are communicating that you are creating a series of forward compatible versions of your package.
I'm very new to python and biopython, currently using a mac. I have python v2.7 and v3.7, and I would like to be learning with python3. Biopython only works on v2.7. Is it worth installing python V3.4 as well as these other 2 versions so I can learn python3 and use biopython? Or remove python3.7 and add 3.4? Even if I install python3.4 will biopython work if it was installed prior? Very confused biologist here.
Firstly, check out this page: https://biopython.org/wiki/Download
You don't have to worry about biopython being bound to a specific version of python - you can use it with either v2.7 or v3.4/v3.5/v3.6. You can also have multiple version installed on your system but I recommend you to focus on digging deeper into one of them. Personally, I work now for several years with python3.x (at the moment 3.6) but I know a lot of people sticking to v2.7.
Having also a bioinformatics background, one thing that I can highly recommend you at the beginning of your journey is taking a course such as:
https://www.coursera.org/specializations/python
There is also a bunch of free tutorials on youtube - you will easily find one that fits your needs by searching for "python tutorial" or "python getting started".
Get yourself comfortable with the language, check out the basics such as data structures, databases, and data visualization. Check also some "python cheat sheets" - they can help you pick up the basic concepts of the language.
All the best and keep on coding!
From the biopython installation document:
Biopython is designed to work with Python 2.5 to 2.7 inclusive. Python 2.7 is the final 2.x series release, and this would be our recommended version (assuming all other Python libraries you plan to use support it).
Upgrading bug-fix releases (for example. 2.6.1 to 2.6.2) is incredibly easy and won’t require any re-installation of libraries.
Upgrading between versions (e.g. 2.6 to 2.7) is more time consuming since you need to re-install all libraries you have added to python.
As of Biopython 1.62 we officially support Python 3, specifically Python 3.3. Python 3.0, 3.1 and 3.2 will not be supported.
Also from the Biopython website:
Python 2.7, 3.4, 3.5, or 3.6 or PyPy, including the Python development header files like python.h
So biopython is inconsistent with their documentation.
I think your best option is to download either the latest version of Python 2 or 3 and see if it works.
Using Ubuntu 16.04.
I was doing development in Python2.7, although recently moved to Python3.5, both of which come by default. The problem is, I find all the python libraries have to be reinstalled or downloaded for the next Python3. Also, the behaviour of Python seems weird because to execute the same script in python3, I have to enter in terminal
python3 script.py
which is different from other applications where I do not have to give the version number. Anyway, the questions I am trying to find answers are
To what extent are the libraries, packages (such as pip etc.) shared between 2.7 and 3.5? Or do I need double installations (and double the space) for everything now? A bit space limited in my old laptop.
Most of the installation instructions and commands I find online do not specify whether they are for 2 or 3. Given that I have two versions, how do I control/make sure they go to 3.5?
Is it advisable and possible to completely remove everything related to 2.7? Can I keep working with 3.5?
The first thing you need to know is that all official libraries and python tools for python3 got the "3" character to separate them from the previous versions. So, you need to use pip3, and not pip, python3, not python, and the packages are called python-pygame, not python-pygame.
So, to answer to you in order:
Yes, the you have to double the space needed if you decide to use both python2 and python3
Usually, if in the tool name there is 3, it is for python3, and if not it's for python2
Python2 and python3 are completly indipendent (different path, indipendent versions, etc.) so having python 2.7 installed doesn't affect python3 BUT since python 3 is the next version of python 2, it makes it obsolete (in my opinion) so if you don't have enough space for both, keeping python2 is absolutely not needed nor useful
If you want to control your python execution then you have various method or techniques:
For downloading packages according to version
You can use pip{version-name} to download the libraries. Like if you want to download library of python 2.7 then write
pip2.7 install package-name
for python 3.5 then use
pip3.5 install package-name
For execution of program:
If you want to execute the program accoridng to you choice of version then just use
python{version-name} script.py
eg:
python2 script.py
python3 script.py
or you just write down the path of your python version on the top of script. Please refer this for more details:
Why do people write #!/usr/bin/env python on the first line of a Python script?
I have the default Python 2.6.1 installed as /usr/bin/python and Python 3.1.2 installed in /usr/local/bin/python3.1. Considering that I use only 3.x syntax, is it safe to replace the default interpreter (2.6) with the 3.1 one (python-config included) using symlinks (and removing old Python binary)? Or is the system relying on the 2.x version for some purpose I don't know?
If you're only using Python 3, start your scripts with:
#! /usr/bin/env python3.1
And you'll be using the right version, without doinking the system about.
edit: BTW this idea is suggested by the Python docs. Each script will be running the version of Python they depend on. Since Python 3 is not backward compatible, it seems dangerous to be replacing the Python executable with one that will break scripts other utilities may rely on.
You can not safely replace the system supplied python. I cannot find a Mac-specific reference for you... but some recent Python versions are not backwards compatible... Many scripts made dependent on an older version of Python will not run on an upgraded python. OS X Comes with Python pre-installed because it has dependencies on it.
Try using VirtualEnv instead.
Update: Just came across python-select from macports which may solve your problem.
Don't replace / remove any binaries unless you are in dire need for storage. In that case too, the mileage is very little in removing them.
You can simply make 3.1 as default with :
defaults write com.apple.versioner.python Version 3.1
There are other ways to ensure that you use 3.1 by default, I have not used them though.
export VERSIONER_PYTHON_VERSION=3.1
Various software installations on my laptop each require their own particular version of Python. ViewVC requires Python 2.5 and Blender requires Python 2.6. Mercurial (thankfully) comes with its Python interpreter packaged in a DLL in the Mercurial installation itself.
How do I get by without having to install the entire Python environment each time? Is there some minimal installer which will install the bare minimum without affecting other programs? Can I modify the Blender and ViewVC installations so that they too use their own Python-in-a-DLL?
It's hard to know which "bare minimum" the Blender scripts you'll want to use in the future may be counting on (short of the full Python standard library, which isn't all that large in term of disk space after all). Why not install both Python 2.5 and 2.6? They can coexist nicely (if your scriptable apps use hashbangs like #!/usr/bin/env python instead of specifically mentioning python2.5 or python2.6, you may need to trick out their PATHs just a little bit).
You should be able to get away with installing the Python binaries in the same tree as the specific application I believe (Totally untested hunch though).