7% of Python Developers Are Still Using Python 2, Annual Survey Finds (infoworld.com) 53
"Python 3 was by far the choice over Python 2 in a late-2022 survey of more than 23,000 Python developers," reports InfoWorld, "but the percentage of respondents using Python 2 actually ticked up compared to the previous year."
Results of the sixth annual Python Developers Survey, conducted by the Python Software Foundation and software tools maker JetBrains, were released September 27. The Python Developers Survey 2022 report indicates that 93% of respondents had adopted Python 3, while only 7% were still using Python 2.
In the 2021 survey, though, 95% used Python 3 while 5% used Python 2. In 2020, Python 3 held a 94% to 6% edge. Dating back to 2017, 75% used Python 3 and 25% used Python 2...
The 2022 report said 29% of respondents still use Python 2 for data analysis, 24% use Python 2 for computer graphics, and 23% used Python 2 for devops. The survey also found that 45% of respondents are still using Python 3.10, which arrived two years ago, while just 2% still use Python 3.5 or lower. (Python 3.11 was released October 24, 2022, right when the survey was being conducted.)
Other findings from the survey:
The 2022 report said 29% of respondents still use Python 2 for data analysis, 24% use Python 2 for computer graphics, and 23% used Python 2 for devops. The survey also found that 45% of respondents are still using Python 3.10, which arrived two years ago, while just 2% still use Python 3.5 or lower. (Python 3.11 was released October 24, 2022, right when the survey was being conducted.)
Other findings from the survey:
- 21% said they used Python for work only, while 51% said they used it for work and personal/educational use or side projects, and 21% said they used Python only for personal projects.
- 85% of respondents said Python was their main language (rather than a secondary language).
- The survey also gives the the top "secondary languages" for the surveyed Python developers as JavaScript (37%), HTML/CSS (37%), SQL (35%), Bash/Shell (32%), and then C/C++ (27%).
- When asked what they used Python for most, 22% said "Web Development", 18% said "Data Analysis," 12% said "Machine Learning," and 10% said "DevOps/System Administration/Writing Automation Scripts."
If there are 11.3 million Python users (Score:4, Interesting)
Then we should be able to ignore the 800k of developers still stuck on 2.x
Full disclosure, I'm a C developer and I mainly stick to international standards from 1999 and 1989/1990. Sometimes intentionally ignoring recent standards (2017) for business reasons.
When C was young and immature, it would have been pretty frustrating for people to stick to some sub-dialect of K&R C. People did do this back in the day, but a fair amount of effort went into dragging people kicking and screaming to "ANSI C". By 1999 standard, most were willing to drop using old K&R C and move to the old 1989/1990 standard while shaking their fists are the new-fangled C99.
So it does boggle my mind in two contradictory ways. I feel like the Python community could learn some lessons in human behavior from the well known struggles C users faced over the past 40+ years. When a language is new, there is a benefit for moving to the latest standard. Especially if it is a good standard. Out with the old, in with the new. Once a language matures, the are many different camps that have their own reason for refusing the new standard. There is probably little sacrifice to using an older mature version versus a newer mature version. So does refusing Python 3.x mean those people are behaving foolishly and in a self-destructive way for not supporting the maturing of a language. Or is Python 2.x already a mature version that deserves some long-term support. My guess is the answer varies among camps, but my own view is Python 2 isn't really that mature and people learned a LOT over the years and fixed some real warts with Python 3.
Re: If there are 11.3 million Python users (Score:2)
You can take my K&R book from my cold, dead hands!
Re: (Score:2)
You can take my K&R book from my cold, dead hands!
Which K&R? The 1978 original or the 1988 ANSI update?
Re: If there are 11.3 million Python users (Score:2)
I have both
Re: (Score:2)
It is like the Bible. You can edit and write different versions, translations and editions but it is still the Bible.
Praise be, amen!
Re: (Score:2)
The main difference between C and Python is that a late version C compiler is able to compile old C code. Not happily since I'd expect a number of warnings about "old style" but it would go through in most cases.
With Python 2 v.s. Python 3 you are in a world of transition headaches. That's why Python 2 still is around.
Breaking backwards compatibility on a language is usually a god recipe for creating headaches.
Re: (Score:3)
1209 Barley Mill Road in Wilmington, Delaware.
An AC keyboard warrior, ooooh scary!
Come by anytime, tough guy! Bring friends.
Re: (Score:2)
I'll order a Barbie doll for you!
Re: (Score:2)
I'm not Joe's typical sex abuse target so I'm ok.
Re: (Score:2)
It must be fun having to deal with the all the security every time you want to go out.
Re: (Score:2)
Who says I don't live/work there? AC should come by and try the tough guy internet keyboard warrior routine. "I'm here to beat up someone from the internet, are they home?"
Or we could do it like we did as kids behind the 7/11 at midnight. Lol, this place is so hilarious.
Re: (Score:3)
So no stubburn IT guys sticking to what was hot when they still had all their hair. Software was just lower in the hierarchy.
Re:If there are 11.3 million Python users (Score:4, Interesting)
The difference between C and python though is that C was designed carefully by engineers with a pretty well understood target. They wanted a macro assembler that could give them some architecture portability.
They built that and even as people wanted to add more features it was more or less backward compatible, you can take a K&R program and make it build on C99 with a moderate effort.
There is a lot of python 2.7.x code where anything but a total rewrite, not re-architecture (although in a lot of cases new language features would me you should do that too) but a rewrite or translation will do to get your code to 3.x.
Python is a trying to be all things to all people, its got to big a foot print to migrate cleanly. Python 2.7 is to Python 3.x as VB is to VB.Net. 3.x not really the same language at all and it should not probably be thought about as such, just looked at something that shares some history syntax.
Re: (Score:3)
There's also versions of 3.x that are incompatible with version 3.(x-1).
Writing anything that's supposed to be used a few years from now is a joke in Python. I've lost count of how many times I've downloaded a Python script and been unable to use it.
This is made worse by every script having dependencies on some external library or other, which will also break even if you install the right version of Python to run the main script.
Re: (Score:1)
Re: If there are 11.3 million Python users (Score:2)
A venv doesnâ(TM)t fix the issue where I need to use Lib A and Lib B, but lib A needs lib c v 3.x-2 and lib b needs lib c v 3.x
Re: (Score:3)
It took C 33 years to get from K&R to C11. Python is not even 30 years old right now.
Re: (Score:2)
Not trying to detract from your points which are still valid, but Python is, in fact, 32 years old from first public release.
If you just want to count from big early releases with popularity spikes (ie, when we got something useful to a lot more people), 1.5 is 25 and 2.0 is 23. 1.5.x was when I first started using it.
Re: (Score:2)
Re: (Score:3)
No, Python should stop changing willy nilly.
Perl, PHP, Python, even C# .NET to some extent, all do this thing where they remove functionality, even on point releases.
A lot of 2.x python is running things like old versions of blender, embedded scripting languages, and so forth. The problem isn't "people are still using Python 2" it's "The developers of Python needlessly release a new point release and break everything every few months. It's like Python picked up the worst habits of both PHP and every NIH (No
Re: If there are 11.3 million Python users (Score:3)
I'd again draw parallels with C. Basically nobody writes code for B anymore, everyone has moved on. The flaw in Python is that their early versions became widely available, perhaps before the language was ready to be set in stone.
Re: (Score:3)
GIMP 2 uses Python 2 (Score:3)
The scripting language for GNU Image Manipulation Program 2.10 is still either Scheme or Python 2. GIMP for Windows bundles its own Python 2.7 runtime, and every Windows user who develops Python scripts for GIMP is therefore a Python 2 developer. Desktop Linux distributions that stopped carrying Python 2 after the end of support of Python 2 ended up turning off Python scripting entirely in their GIMP packages, leaving only the more obscure Scheme interface. Though the Python interface of forthcoming GIMP 3 has been ported to Python 3, there is no estimated time of completion for GIMP 3. As ChameleonScales wrote in this post [gimp-forum.net]: "So right now we're in a gap where neither the python2 nor the python3 api are "officially" provided. This isn't ideal but at least I understand the situation better now."
Re: (Score:2)
So it means that GIMP3 will not work fully on windows 7.
Yes, as retarded as it may sound, python doesn't work on windows 7 since version 3.9.
How can one major programming language work on linux and not on x64 windows 7 just boggles the mind.
Re: GIMP 2 uses Python 2 (Score:2)
The mentality of "it works on my machine" is part of the version madness that seemed to have fed Python's popularity rather than extinguishing it.
Re: (Score:2)
The string type isn't a plain binary array, but python 2 programs treat it like it is.
Re: (Score:2)
Strings absolutely are arrays of binary objects. The difference is that Python 3 changed them to a less useful array type.
In Python 2, strings were arrays of bytes. The problem was that it defaulted to defining those as ASCII bytes, which was really stupid given that Python 2 was released in 2000, seven years after UTF-8 started to be adopted as a standard. One could override that default, but it was relatively uncommon to do so.
In Python 3, strings are arrays of Unicode code points, which are often more
Re:Why break compatibility? (Score:5, Insightful)
Because Guido and the entire team behind it clearly had no actual experience in using programming languages for serious business and so did most of the users to be honest.
There are some actual improvements yes, some things were made more elegant but Python is full of inelegant design choices to begin with and a very quick and dirty language which is especially why it shouldn't be breaking anything at all because people want to use it to get something small done quickly, and then never have to worry about it again. The new and “improved” string handling which could also be accessed in Python2 isn't even objectively better and leads to many issues when handling input that isn't well-formed UTF8 that people might not expect.
It's not just the 2->3 upgrade that's a mess, even within 3, one often see scripts breaking on one's system and has to download new modules which usually are backwards compatable, but sometimes aren't.
It's a language for and by people in this culture I notice far too much of, the culture of people that don't understand that for many people and especially companies, time is indeed money, that people don't' want to spend time on something because it literally costs them money. People say “Well, just upgrade all your python2 code to python3” like it doesn't cost a lot of time and thus money. They're telling a company, “Well, just pay a million euros”. And it isn't only the time spent on upgrading, but the risk of introducing regressions when doing so and touching something that currently works which many companies are even more affraid of because regressions and creating downtime while they're being fixed costs even more money.
There's a reason most serious projects take backwards compatibility very seriously and break things only to fix data-critical bugs; they don't break things to make things slightly more elegant or they make the new changes opt-in because new code being littered with pragmata at the top asking for changes everyone now uses is better than ever breaking anything.
Re: Why break compatibility? (Score:2)
It sure as hell wasnt for runtime efficiency. Python is still one of the most CPU hogging languages out there.
Sometimes you have to (Score:4, Insightful)
Not all python projects end up in pypi as a public library. Sometimes you have to maintain a company application for which there is no budget to rewrite and youâ(TM)re stuck with it.
At this moment i maintain a VIsual Basic 6 application that runs on Windows XP because it drives a custom piece of hardware that cannot be migrated to anything else.
Re: (Score:2)
Ouch. :(
I see stuff like this all the time, because, frankly, we've failed to get management to understand that software rots without sufficient maintenance, and the more it has rotted, the more it costs to fix.
It's like letting a car go without oil changes until it finally lets out the magic blue smoke.
Versions of programming languages? (Score:3, Insightful)
Why are we acting like it's a totally normal thing for programming languages to have versions that become deprecated, and due to security issues, no less?
Re: (Score:2)
Because language design, not only implementations, also may have bugs that preferably should be fixed?
Granted, actual security bugs are mostly in concrete implementations, but some some features - like for example PHP database API:s making SQL injection easy are more or less a security bug in the design. (long time since I used it, so perhaps changed now).
And for versions to become deprecated is also a matter of effort to maintain. For open source, it's easy - if you like the old design better, you are free
It's something a bit more complex (Score:3)
Usually when you make your programming language go into a different, incompatible, direction, you'd just make a new language. Borland did this when they changed their Borland Pascal to Delphi, for example. Now for Borland this coincided with the switch from MS-Dos to Windows, and it happened at a time when computers and operating systems were switched within a very few years. Essentially Borland Pascal software would be outdated shortly after Delphi came out. So essentially there was no harm in doing that.
Re: (Score:2)
Security isn't exactly a steady process. Discovering security issues usually means that you find something in a language, program, operating system or even hardware that nobody had seen earlier. Sure, there are a few things that could have been foreseen because they rely on older security issues, but a lot of the relevant security holes happen when someone discovers something really new that nobody had taken into account before.
And yes, that may affect programming languages and their design. There are some
Python 2 will live a long time (Score:1)
The cool kids with their throw-away web stacks were berating Python 2 ten years ago. They could not believe there was little motivation to migrate, some Python is so intricate and esoteric that even the authors would have been daunted, but at least knew how to test it. It was a failure of the community to abandon support for it, a regrettable decision, so after all this time I really can't resist saying it: I told you so.
Re: (Score:3)
some Python is so intricate and esoteric that even the authors would have been daunted
Translation: Some of the early Python code was hacked together by people who could barely program because Python is a pretty easy language to learn, but who also had zero experience with programs spanning more than maybe 100 lines, which created so terrible spaghetticode that nobody in their sane mind would want to maintain it and rather write it from scratch because it's less work.
Python is my job and I love it (Score:3)
but there's one thing I hate about it: even at version 3, and as mature as it is, backward compatibility is broken on a regular basis. And even if I maintain my code to work with the latest and greatest, many modules I need to import do not.
I can't count the number of stuff I pip-install that won't install because some dependency has changed or disappeared, or it will install but it won't run properly without fucking around with the module whose author hasn't adapted it to the new, incompatible Python feature yet.
As a result, at my company, I surveyed all the Python modules we need (not that many and only big ones, as I try to reduce our exposure to supply chain attacks), determined the latest version of Python with which all the modules work out of the box, made local copies of all of them and the language installer, and basically froze everything we use at Python 3.9-something.
Now I basically review all the versions every 6 months but it's fewer headaches so get off the upgrade treadmill. Especially since our applications are local and pretty much don't do anything outside of our heavily walled-off intranet.
Re: (Score:3)
A REAL PROGRAMMER knows the REAL differences between backwards-compatibility and dependency issues.
Oh my God, thank you so much! After 30 years I finally know how to become a real programmer!
Re: (Score:3)
That's why I use perl for such stuff. I tried python before, but the python developers showed too little respect and consideration for backward compatibility.
That's mainly because the Perl developers attempted to do something even *more* stupid than the Python 2 to 3 transition. So stupid, in fact, that they had to give up on it after over a decade of toil and admit that they had actually come up with some new monstrosity that's not Perl at all.
It only looks like they respect backward compatibility because they were off in the weeds for all those years and too distracted to do anything to the existing language.
Whatever happened to Python 1? (Score:3)
Just curious. Maybe in dark forgotten corner someone is still using it while cursing that new fangled version 2.
Re:Whatever happened to Python 1? (Score:4, Informative)
I started a project at work on Python 1.5, and it was a bit disruptive when I had to move it to 2.0, and even 2.1 was some disruption from that. I continued supporting that project for between 10 and 15 years and kept it at Python 2.x even after Python 3 was out.
At the time I figured I would be retired before I needed to move to Python 3, but I was wrong. I ended up moving to 3.x several years before retiring this past spring. Part of the problem is that RedHat Enterprise last I knew shipped Python 2.7 by default. The company also had local installations of Python 3.x, and both versions had semi-overlapping additional libraries, which was quite annoying. I actually had some code that was split between the two versions and passed intermediate data between them.
Old Environments. (Score:3)
The old diagnostic and debug environment we used on old chips was in Python 2. It got updated to 3. But when we drag out old chips to work on, the old environment comes out with it. So I maintain both Python 2 and 3 versions of the test code.
I feel for the python2 users (Score:3)
When you invest in a programming language you expect that it should be forward compatible, mostly anyway. Perl does a pretty good job of that.
Python 2 to 3 migration isn't always trivial. I'm not surprised a large portion of people are still using it, if anything that's a sign of difficult forward migration.
Will migration to whatever Python 4 looks like be equally difficult?