Are you still using Python 2.7?
If so, why?
Do you know Python 3 is 10 years old?
A lot has changed since the early days of Python 3.0, today most frameworks and libraries either support both, have dropped Python 2 or are about to do so.
Python 3 is better than Python 2 (and is about the same speed). Also Python 2 is not going to be maintained at all by 2020 and has been in feature freeze for a long time (since 2010 I think).
If you are still using Python 2.7 daily at work without a plan to migrate in sight, please talk about it internally. If the reason, for you being stuck at work on Python 2, is a specific third party library that hasn't been migrated so far, please ask your company to actually fund the open source project so they can migrate ;-)
Python has been around for 27 years, Python 2 18 years, Python 3 10 years and the Python community is bigger than ever. The investment in Python 3 is definitely worth it.
Let's talk about it and if you need help to make the decision I think I can help.
Top comments (43)
Non python developer here
hahaha one of my favorite gifs ever :D
In my personal projects, I use Python 3 whenever possible - however, I was working on a project last year where I felt compelled to stay with Python 2, because the run time of that project went from 3 hours to 6 and that wasn't ok with me. (For background: I was parsing Wikipedia dumps). Are there any tricks I should know about regarding speeding up I/O on Python 3?
Woah, double the amount is odd. What were you using to parse in Python 3? Do you remember?
It was a third-party wikipedia parsing library (github.com/joaoventura/WikiCorpusE...) - maybe I should profile it and see where the bottleneck is!
Good idea, that's where you want to start for performance improvement anyway :-)
It seems you mostly use part of the standard library that hasn't changed with Python 3, it should be easy to test with Python 3.6 as well.
Let me know if you decide to do it and what results you get!
So I did a little bit of profiling on a subset of my wikidump data - a quick glance showed that bz2 decompression was way worse on Python 3. When I tried on decompressed files, the Python 3 cost was only 20% rather than 100% - so that's progress! I'll probably take a deeper look tomorrow.
I should clarify that I'm on Python 2.7.15 and 3.6.5 - I wonder if the newly released 3.7 would help?
Yeah, and if you can isolate the issue with a gist that I can take a look at I'm happy to do so!
I see nothing related to bz2/bzip2 in Python 3.7 what's new page: docs.python.org/3.7/whatsnew/3.7.html
Are you using Linux, MacOS or Windows?
Linux
Also, if you want to try this out, I'm using a dump file from the Russian Wikipedia (such as dumps.wikimedia.org/ruwiki/2018062...), and just extracting the list of documents via
WikiXMLDumpFile(filename).getWikiDocuments()illustrates the difference in timing. You'll need to patch the code to behave with Python 3, though!Can you maybe just commit your branch for Python 3? You'll save me some work ;)
Sure - I can fork it and submit my changes there after work!
Thank you!
Thanks for offering to take a look; here's my fork with the Python 3 change: github.com/hoelzro/WikiCorpusExtra...
...and here's a gist using it: gist.github.com/hoelzro/80561443fe...
After digging in a little bit, I noticed that the
bz2.BZ2Fileclass is substantially slower in Python 3; usingbz2.decompressorbz2.BZ2Decompressoris a lot faster! The former, of course, requires enough memory to hold both the uncompressed and compressed contents, and trying to use the latter is a more cumbersome and one might reintroduce the same overhead thatbz2.BZ2Filehas if one implements the line splitting logic on top of it. I'm curious why BZ2File is slower in Python 3 - maybe I'll have a chance to dig in further tomorrow!Using the command python3 feels to me like I am still using a preview version, and 'python' command defaults to python 2.
Maybe more people feel the same, but I haven't used python lately, sorry xD
Eh eh, a preview version that's 10 years old ;)
If you want to experiment with Python without touching OSX default version (which I recommend anyway) you can check out pyenv
And the countdown is happening at pythonclock.org/
Itโs important to note that even security updates will stop for Python 2 on 1/1/2020, so, depending on your use case, โwhy switch if 2.7 worksโ may not be a good enough reason not to switch for much longer. ๐ฎ
Exactly :-)
Not having security fixes for ever and ever (and honestly, also no language evolution) might be a deal breaker. I feel like some Python devs are underestimating this part and properly not talking about it within their own teams but it's just a feeling. I have no hard data to back that up.
I tried to change to python 3.6.5 because I have 2.7,
But I didn't know that cinnamon use python 2.7 and when I erased all 2.7 cinnamon stopped and all their applications didn't work.
Now, I installed python 3.6.5 but I still have 2.7,
I read that you recommend to use pyenv to use python without touching the default environment. I going to try that.
I use Slackware Linux.
Yeah, I definitely recommend pyenv. You can keep your packages on 2.7 and try 3.6 or 3.7 alongside with it.
pyenv is independent from the distro packaging system
Our target platform is RHEL 7.x, and that still ships Python 2.7 as the default. (In fact, we were on RHEL 6.x, and that shipped Python 2.6, so we only bumped to Python 2.7 recently.)
It's understandable, distros are the speedier to change. I think version 8 is going to drop python 2, so take it into account.
I don't know what you do but maybe you can start considering targeting both versions. It will help in the future.
Is there a reason why you can't install a different version of python and ignore the pre installed one? Again, I don't know what sort of tools you are writing at work
Yeah, we'll probably have to upgrade to Py3 compatibility eventually, but we've got lots of other stuff on our plate for now.
We actually do use
cx_Freezeto build our services, so in theory it's only the version of Python in our build environment that matters. Realistically, though, adding a custom Python version that's not part of the baseline RHEL distro would add overhead and hassle to our workflow and requirements right now, and there's no immediate reason to move away from Py2.7 atm.Yeah I totally get it, that's why I suggested for people to initiate a conversation about it in their own teams. 2020 is not that far. Python 2.7 is battle tested but having no support or security fixes can be an issue if you have customer facing apps.
I agree with the hassle :-)
Not all codebases could be migrated to Python 3 yet have more benefits from it (time, bug fixes, etc.). And about security issues... Should I be worried about that if my application is offline completely?
What do you mean by completely offline?
Like a desktop application or a script not connected to the internet or an app on an offline computer?
A desktop app that does not require internet at all.
Well, then no. If you don't require new language features and you can be reasonably sure there are no language bugs you require to be fixed then you can stay on Python 2 lane.
Just make sure, if it's an app that is going to be improved for the years to come, that any framework you use as a plan for the future. Maybe the language won't be an issue but what if the particular desktop framework you use has forked a new version for Python 3 and stopped developing the version for 2?
In the beginning most people didn't migrate because frameworks were not ready for Python 3, now a lot of frameworks plan to remove support for Python 2. Django 2 is Python 3 only, for example.
I agree if it's internal tools and system software. I disagree if any of it is customer facing.
2020 is not that far away and having no support nor security fixes could be troublesome down the line.
BTW Python 3.7 was released yesterday :P
I'm currently teaching Python in a private learning institute since 2015. The first year they told me to stick with Python 2.7, as that was the version used by the former teacher, but since 2016 I've switched to version 3.5 and never looked back.
My goal is to teach students to allways upgrade their tools and keep up with new trends in technology, so using Python 2 seems like a contradiction to that moto. And the benefits are not only using a more up-to-date version, but version 3 seems to be more comfortable for me (why do they include print without parentheses in version 2 was a big question I had).
Hi Juan, well done.
Regarding print it's just because it used to be a statement, not a function like now. Why? I don't really know, the initial version of the language was designed back in 1989 ๐ฑ
I work with an ERP called Odoo which has been based on Python 2.7 since its first version. It only switched to Python 3 since last version which was released last year. The main issue faced is that it is very time costly to migrate from one Odoo version to another when there are custom made module on top of the base ERP solution. Most customer don't really see the benefit of switching to the newest Odoo version nor python and no one will do it for free sadly.
So I believe they're going to stick with decommissioned Python 2.7 after 2020. Hard to explain the benefit of updates when there is money at stake...
I understand perfectly. ERP products are hard to migrate.
Well, if they new Odoo version does not offer anything compelling to them then... the customer is always right, no debating on that :D
You can monitor the changes since the 11 version and see if they start implement features which will improve your customers modules and/or justify the migration.
Still, getting familiar with Python 3 is worth it anyway (even for professional reasons as a Python developer)
Oh yeah, I definitely prefer to work with Python 3!
Yeah, I hope they come up with great new features that will justify migrations!
I'm currently working in the PLM/ERP field, where currently almost every customer has it's own on-premise installation with (sometimes) thousands of lines of customizing (the biggest one I know of has a size of about 300kLOC). Migrating all these installations to work with python3 is a huge effort. So management/CTO hesitated to drop python2 support so that customers could update their installations without having to migrate their code.
Right now, we plan to make the cut with the next major release (due early 2019, if I remember correctly) while providing long term support for the current one, even after 2020.
Good luck for the next release! Sounds like a solid plan!
I used it on a bot project in its beginning until I faced some issues with Python 2. Python3 is way WAY better.
What sort of issues did you face?
Here's there an interesting story on how Python 3 went from non-existent to practically the dominant version at Facebook in 4 years: lwn.net/SubscriberLink/758159/f1f6...
Not able to install PySide2 on Python 3. Using Anaconda. PySide is not compatible for Python 3. At last ended up using PySide on Python 2.
I've never used PySide2 but apparently it's supposed to work on Python 3 as well: wiki.qt.io/Qt_for_Python/GettingSt... - Maybe check the mailing list to see, the wiki talks about issues with Python 3.6.0 but we're at 3.6.6 and 3.7.0
PySide 1 is definitely deprecated according to the website so I wouldn't worry about it being compatible with Python 3