I saw on this tweet that Google Colab move to Python 3.7 on February 2021. As of today however (January 2022), Python 3.10 is out, but Colab still runs Python 3.7.
My (voluntarily) naive take is that this is quite a significant lag.
Why are they not at least on Python 3.8 or even 3.9?
Is it simply to make sure that some compatibility criteria are met?
The only reason is they want to have the most compatible version of Python worldwide. Based on the Python Readiness report (Python 3.7 Readiness), version 3.7 supports almost 80.6% of the most used packages so far. Still, this coverage is 78.3% for version 3.8, 70.6% for version 3.9 and 49.7% for version 3.10 (as of March 29, 2022).
Frankly, if Python 3.6 was not in its EOL, they still used this version today. Lucky us, python.org decide to rid of versions below 3.7. 😊
On the other hand, You can update the Python version in your Colab by running some Linux commands in the notebook. But the problem is that whenever you start a new notebook, google ignores the updates and will turn back to the original version.
The best action that google can take is to have options to select the python version. Because of this, I am not using Colab in most cases, especially when teaching Python to my students.
Update (January 12, 2023):
Now google Colaboratory supports Python 3.8.16. After a long time, we see some improvement. But it's still outdated because the current version is 3.11.1.
Python Readiness report says 80.8% of most used packages support Python 3.8, and 30.6% support 3.11. But we know it comes from info on PyPi. In practice, this support is far more than what the package maintainer says in the repository. Many packages support 3.11, but they still mention the lower version of Python. The reason is the maintainer didn't have a chance to check and update their production yet.
You can use Python 3.10 with this notebook.
Related
I have followed the instructions at https://github.com/mapbox/tilesets-cli/ but since the default Python version is 2.7 on a mac, Python3 is not used. How do I force this?
Rather than trying to shoehorn a tool built with Python 3 into Python 2, I would recommend using a tool like pyenv to manage multiple versions of Python on you device.
Especially given that Python 2.7 is not going to be maintained past January 2020 and macOS is going to remove the Python 2.7 system dependency altogether in upcoming releases (see the "Scripting Language Runtimes > Deprecations" section of the Catalina release notes.)
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.
Does PyPy support the aio and Python 3.5?
I need the performance of PyPy and asynchrous code of asyncio. Also I need to use async/await in my code. Is that possible?
If so, what are the nuances?
The current version of PyPy (version 7.2.0 at the time of writing) supports asyncio on at least Linux and Windows.
Old, now outdated (as of 2019-10-20) notes:
Currently there is a PyPy version (v7.0) compatible with Python 3.5 and a beta version (v7.1.1) compatible with Python 3.6. Both versions support asyncio on Linux (and probably macOS, but I didn’t try myself), but only the latter supports asyncio on Windows.
Old, now outdated (as of 2019-04-16) notes:
Currently PyPy supports Python 3.5, so asyncio should just work. However Python 3.x on Windows is still beta-quality. Unfortunately currently the extension module for overlapped IO, which is needed to run asyncio on Windows, isn't yet implemented.
Old, now outdated (as of 2018-06-10) notes:
Currently PyPy supports Python 3.5. Note that PyPy's Python 3 support is only beta quality in the moment. We are continuously working on improving it. It's not yet production-ready, though. Most code involving asyncio should just work. If not, please check the open bug reports or create a new one or let me know here in the comments.
Old, now outdated (as of 2017-08-18) notes:
Currently PyPy supports Python 3.3. This means that you can install asyncio on PyPy3.3. Note that PyPy's 3.3 support is only alpha / beta quality in the moment. We are however actively working on increasing performance and compatibility with CPython.
The async / await feature was added in Python 3.5. We started a very experimental branch with Python 3.5 support, but it's still got a long way to go. Luckily we have a GSoC student working on it currently, but still it could take several years (depending on how much donations and volunteer work we receive).
EDIT 1: Previously there was a feature missing to run asyncio. It was implemented shortly before this edit. The answer was edited accordingly.
EDIT 2: We just released an alpha version of PyPy3.3. We don't recommend anyone to try the old PyPy3 release supporting only Python 3.2. This is why I rewrote most of the answer.
Old, now obsolete (as of 2016-05-30) notes:
The PyPy3 version from the website is very old and only implements Python 3.2 - we haven't done a release for over one and a half year. Because Python 3.2 is missing the yield from feature, asyncio won't work with this version.
No. According to PyPy website it is only Python 3.2.5 compliant, while asyncio requires Python 3.4 (actually can be installed using pip on 3.3, thanks #dirn). Also on Asyncio Wiki, it is stated that asyncio doesn't work on PyPy yet (though Wiki was last updated in August 2015).
So I have installed python 2.7 in cygwin and it runs without any problem. However, when I install new packages using cygwin's setup.exe, it will always select new version 2.6.8 for the python package by default, and if I don't switch back to 2.7.2, it will uninstall python 2.7 and install python 2.6. What's wrong with my cygwin? Is there any method to fix this problem?
Python 2.7.3 is currently experimental; the current supported version of Python for Cygwin is 2.6.8. Every time you run Cygwin's setup.exe, it sees that the version of Python you have installed isn't the latest supported version, and attempts to "upgrade" you to that version.
Noticing when you've intentionally selected an experimental version of a package, and not "upgrading" you to the stable version would be a nice feature for Cygwin's setup.exe to have. Sadly it doesn't; you just have to remember to change the install list every time you run setup.
(Although if you fancy it, I imagine such an enhancement to Cygwin's setup.exe would be gratefully received by the Cygwin community; it's an open source project and someone has to do the work!)
Jason Tishler, Cygwin's Python maintainer, announced the experimental package in December 2012. To quote his email:
I will update Cygwin to make 2.7.3-1 (or later) current on or about February 1, 2013.
That change will be announced on the "cygwin" and "cygwin-announce" mailing lists, if you fancy following them. Once that happens, the installer will work as you'd like it to.
I think I have figured out what the problem is. In the package selection window, there are three options above the package list, namely, keep, Curr and Exp. The default one is Curr, which means that cygwin will select the most stable version for each selected package. In some way, python 2.6.8-2 is considered more stable than 2.7.3-1, and then each time the 2.6 version is selected. The only way is to switch to Keep option, but then we will not update other packages as well. This is quite annoying.
I want to use PyPy with Python 2.6. The default version (PyPy 1.4.1) seems to be 2.5 when downloading binaries. Google doesn't seem to be helping much, advice?
You can download a nightly build if one exists for your platform. They support Python 2.7 and an official release with this support is supposed to happen in the next days, as PyPy developers are sprinting at PyCon right now.
Edit: As of 2012, PyPy stable releases support Python 2.7 and there is ongoing effort to support 3.x.
If you use an OS for which no nightlies are available, you can still build PyPy from source using latest code from Mercurial. You'll need a somewhat beefy machine for that and building on Windows (specially 64 bits) has a couple of hurdles to clear, so you might want to join #pypy in freenode if that is what you need.