Not long ago - about three years ago, whenever someone asked me which Python version should be used for our new project? - I would replay: we start Python 2.7 and later on maybe move to Python 3.x.
One year ago I received similar question: should we start our new project with version 2? - I was very confident in my reply: Nope, we start 3.6 as the proven stable 3 version.
Today, believe me or not, for starting a project I would already recommend Python 3.7.
My current thoughts on Python versioning are:
- 2.7 is very stable and performant, but will not be supported after 2020.
- I have the feeling 3.6 is used in most new projects today. Is my feeling right?
- 3.7 has many standard library improvements and the performance is competitive with 2.7 - see here. These I know also from experience.
- Python >= 3.8: After the BDFL proudly left the building, and I say this with really high respect to Mr.Rossum, a new governance model was introduced. I am looking forward to see if this will have negative / positive effect or no effect at all.
My questions for you are:
- Which Python version is your current live project using?
- Which version would you recommend for starting a new project?
Top comments (22)
I started a project a few months ago called yaml-resume and I chose to support python 3.5+.
To me, it makes no sense to start a new ptoject in python 2.7 as it as (almost) reached end of life.
I dev with 3.7 but I use travis to ensure it also pass the tests in 3.5 and 3.6. I even had 3.8-dev but due to dependencies not supporting it I had to drop the next python release for now.
Yes, Maxime, absolutely valid points.
What I am observing - and I am not commenting if this is right behavior or not - is that many companies still have not refactored their 2.7 project to 3.xx! But they have had many years to plan this?!? Maybe they do not care much of the potential security issues, because they use 2.7 for internal projects, not Internet facing.
I am not sure all Linux distributions are ready to ditch completely 2.7 also. Ubuntu is working towards this, but I think they will use version 2.7 for some time after 2020.
About version 3: I am really keen to break all the compatibility prior version 3.7 in each and every new project, because I like it's features very much, but as you say - maybe it is good to write code, compatible with 3.6 and maybe also 3.5...
BTW, congratulations for your project yaml-resume, I will take some time to review it!
Thanks. I was planning to write a post about it when I reach version 1.0 😄
Unfortunately 2.7 is not likely to be dropped soon : some dependencies are not always 3+ compatible, some companies are using homemade software they do not maintain anymore but they can't/don't have time to replace...
Regarding versions prior to 3.7, I think making sur your projects are supporting them is useful because a lot of linux distributions are using rather "old" software. For example, red hat 8 or ubuntu 18.04 both have 3.6 as default python3.
Of course if I need to add a must have feature and it breaks somehow 3.5 support, I'll probably do it 😉
About reaching version 1.0 for your project: Consider posting and discussing prior reaching maturity. This is my personal opinion though, you don't need to follow it... but maybe the community will give you more ideas for your project and you could incorporate better ideas in your version 1.0 :)
My thoughts about Python backward compatibility are - maybe we need to bother with 3.5 and 3.6 backward compatibility only for our public projects - because we do not know which version our users are forced to use... For new live projects, used only by your employer, where you control the environment - I am still convinced we should start with 3.7 and break all backward compatibility...
Totally agree with the last point.
I might make the article before release then. Just want to have something more than just an idea before.
Really? Are there actually some libraries that aren't 3.x compatible? Can you give some examples?
I was mostly referring to "homemade libraries" you could find inside a company.
But yes, there are some libraries that aren't 3.x compatible. Check on pypi, you will find that a lot of these have very recent releases.
You even have some awesome and very active projects that have restrictions or offers "experimental support" of Python 3 : for example Click or Jinja2.
Ah, that makes sense.
We're using 3.6 and 3.7. 3.6 only for some scripts, because it is default in current Ubuntu LTS, and 3.7 because we found some of it's features nice and building and running took place in an official Python docker image, anyways - we've constructed the dev workflow in a way that it does not include running the code on the dev machine, which makes it pretty robust against "works on my machine" problems, and it can easily be fixated to a certain python version.
Hi Daniel again,
I reviewed your profile and I realize that your job is connected with even smaller images than Alpine, like your raspberry repository shows.
This is really cool!
Hey Todor, those were hobby, though :-)
oops, my bad, sorry.
Nevertheless, a nice hobby! :)
I have one raspberry pi in the locker in the office and some day I will start playing with it, whenever the time comes :)
Maybe to see what python projects could run there...
Cheers!
Hi Daniel,
This is very nice topic you are bringing up!
About the Docker: a nice surprise for me was that all my 3.7 code is working nicely on top of the 'python:3.7.4-alpine' image. I was too cautious not to use Alpine, but it seams that it is playing nicely with Python. A good extra with Alpine is that the image is smaller than the others...
Cheers!
I am using Python 3.7 now - have been using Python 3 since 3.2 - and will move to Python 3.8 once any dependencies are compatible. In the event you need help with transitioning, the
sixlibrary and the2to3command-line tool are there: The first smooths over the differences, while the second converts your code.Hi Eric,
Thank you for sharing with us!
In a project for migration legacy python 2 code I used
2to3- it is a wonderful tool. After passing the code through2to3there were small number of errors to be corrected manually - usually errors coming from string/unicode incompatibility.Currently I write only python3 code and make it compatible with python2 with
__future__, but after one year this would not be necessary anymore as python2 will be a history already...Cheers!
There is also an inverse tool, fittingly enough called
3to2, that takes Python 3 code doing things Python 2 cannot handle and makes it Python 2 friendly. Why you would do this now, with Python 2.7 - the last version of Python 2 - exiting extended support soon, I do not know, but it exists.Most of my projects I have running 3.6.
I've tried migrating some to 3.7, but I keep encountering issues with celery and kombu not working nicely with django celery beat. I've had to rollback to 3.6.
If it's a django project with celery, I'd stay on 3.6 for a while longer. If it's python without django or celery beat, I see no reason not to go with 3.7.
Hi Alan,
This is good information you are providing, thanks!
As django and celery are not working properly, one can assume that other libraries / frameworks still have problems with 3.7
Maybe the time still has not come for 3.7
Cheers!
I use 3.7.3 and I try to update the python version whenever I need to. I don't do it constantly because it might still be unstable and maybe quite hard to work with. So, I would only update when I NEED to.
I recommend anything above 3.6 because there are a lot of libraries and etc. that need a 'higher' python version.
Hi qwerty,
This is exactly my schedule too... and this is the reason I am asking the question on dev.to - I wanted to see the other people schedule. Thank you for the answer!
Generally when starting a new project - it seams we should start it with the python version, which is previous to the last version (3.7.3 as of today), and also all the legacy applications should be refactored to support at least 3.6 - exactly like you described.
Thanks!
Most of my projects run on 3.7, but I'd recommend 3.8 for new projects.
Fair enough, Carlos. So you are the one of us looking into the future. In case you use 3.8, your new project should go live after at least 3.8.0 final: Monday, 2019-10-21. I personally would not be so brave and I will think of 3.8 at least one year in the future. There will be nice new features, but the one thing I hope to see is "the performance with fundamental speed-up fixes".
Thanks for sharing with us, Carlos!