Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Python Programming

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:
  • 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."

This discussion has been archived. No new comments can be posted.

7% of Python Developers Are Still Using Python 2, Annual Survey Finds

Comments Filter:
  • by OrangeTide ( 124937 ) on Saturday October 07, 2023 @11:57PM (#63909321) Homepage Journal

    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.

    • You can take my K&R book from my cold, dead hands!

      • You can take my K&R book from my cold, dead hands!

        Which K&R? The 1978 original or the 1988 ANSI update?

        • It is like the Bible. You can edit and write different versions, translations and editions but it is still the Bible.

          Praise be, amen!

        • by Z00L00K ( 682162 )

          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.

    • Worked in a lab environment a while back. Expensive hardware, order of 10s of k€ for a machine. API for those machines were mostly written in Python 2.x. That was the main reason to stick to 2.x. There was a gradual move to 3 there, but pretty sure there are still hardware interfaces that need 2.x.
      So no stubburn IT guys sticking to what was hot when they still had all their hair. Software was just lower in the hierarchy.
    • by DarkOx ( 621550 ) on Sunday October 08, 2023 @06:57AM (#63909635) Journal

      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.

      • 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.

    • by Sique ( 173459 )
      C is just the compiler, to compare it to Python, you have to include at least libc. And if you look at your code, how much of it would run compiled against e.g. a C89 libc? Are you using wchar.h? Do your code needs at least needs NA1? Which of your code requires C99 (e.g. stdint.h), or even C11 (threads.h et. al)?

      It took C 33 years to get from K&R to C11. Python is not even 30 years old right now.

      • by DeSigna ( 522207 )

        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.

        • by Sique ( 173459 )
          As I am counting from K&R 1978 and not from the reimplementation of Unix R3 in C as Unix R4 in 1973, it is also fair to count Python from the first mayor public release.
    • by Kisai ( 213879 )

      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

    • C has a better but also worse interface though and that's helpful. Worse is better and all that. If you took all the dependencies you use in your programs and tried to compile them all from source using the same compile parameters you use in your own programs I doubt you'd get very far. C obviously doesn't intend you to do that, you instead compile with whatever settings are needed to object files and then libraries and you can combine those with your own program through the interfaces that are set in stone
  • by tepples ( 727027 ) <tepples.gmail@com> on Sunday October 08, 2023 @12:13AM (#63909325) Homepage Journal

    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."

    • by Saffaya ( 702234 )

      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.

  • by Ubi_NL ( 313657 ) <joris.benschop@[ ]il.com ['gma' in gap]> on Sunday October 08, 2023 @12:32AM (#63909345) Journal

    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.

    • 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.

  • by ForTheVeryLastTime ( 1777610 ) on Sunday October 08, 2023 @01:59AM (#63909383)

    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?

    • by pereric ( 528017 )

      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

    • 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.

    • 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

  • 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.

    • 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.

  • by Rosco P. Coltrane ( 209368 ) on Sunday October 08, 2023 @03:14AM (#63909417)

    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.

  • by Viol8 ( 599362 ) on Sunday October 08, 2023 @04:25AM (#63909479) Homepage

    Just curious. Maybe in dark forgotten corner someone is still using it while cursing that new fangled version 2.

    • by dpilot ( 134227 ) on Sunday October 08, 2023 @10:20AM (#63909849) Homepage Journal

      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.

  • by TechyImmigrant ( 175943 ) on Sunday October 08, 2023 @07:28AM (#63909649) Homepage Journal

    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.

  • by eneville ( 745111 ) on Sunday October 08, 2023 @03:09PM (#63910375) Homepage

    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?

"I shall expect a chemical cure for psychopathic behavior by 10 A.M. tomorrow, or I'll have your guts for spaghetti." -- a comic panel by Cotham

Working...