back to article Python 2 bows out after epic transition. And there was much applause because you've all moved to version 3, right? Uh, right?

The final official release of Python 2 arrived on Tuesday, marking the end of two decades of work. Python 2.7.18 "is the last Python 2.7 release and therefore the last Python 2 release," said Benjamin Peterson, release manager for Python 2.7, in a post to the community mailing list. "It's time for the CPython community to say …

  1. gerdesj Silver badge

    lol

    Python is demonstrating how to do a breaking change. There is no perfect way to do this and you will never get away from someone claiming that they paid for something with promises.

    The timescale was adjusted once the scale of the problem was known and in response to reasonable complaints. The timescale was/is a very long time.

    1. Anonymous Coward
      Anonymous Coward

      Re: lol

      Still trying to get $JOB to care enough to upgrade the (internet facing) Django 1.3, Python 2.6 apps :/

      1. bombastic bob Silver badge
        Unhappy

        Re: lol

        Django? I had to deal with that, at one time. *shudder* - it re-defines new levels for BLOATware.

        My solution to MANY of the problems it CAUSED by Django (and bad python code) was to write C language utilities to do REAL work with reasonable performance, and then call the programs from the Django Python code [instead of trying to gerrymander Python code] and not only made it work properly [from the user perspective], but made it way more than 10 times faster in the process. That code should NEVER have been done in Python to begin with...

        It was also the first time I'd seen upstream feature creep break an installation. I figured out how to force Pip to ONLY load specific versions of things to prevent breakage, just so I could work on it. It was sad.

        1. Morten Bjoernsvik

          Re: lol

          >My solution to MANY of the problems it CAUSED by Django (and bad python code)

          >was to write C language utilities to do REAL work with reasonable performance,

          Django the swiss army knife of python.

        2. unimaginative
          WTF?

          Re: lol

          Most of what I do is Django. its is brilliant. Yes, its big, but it does a lot and is flexible.

          If you had to "figure out how to force pip to only load specific versions of things" you are obviously not familiar with the tools you were using. its standard practice to have a requirements.txt file with versions specified (and you can have a range, so you can say allow minor version upgrades but not major, or patch only).

          If you were using Python for things that should have been done in fast compiled language you are using the wrong tool for the job. You can write a C extension, or rewrite Python code in Cython, or JIT compile performance sensitive code with numba or run the whole thing with Pypy, etc.

          Of course, with Python you often find that someone else has already provided a fast library. This is where most of my efforts to use something other than Python come to grief - its always easier to use the Python library.

    2. bombastic bob Silver badge
      Meh

      Re: lol

      I have a suggestion: why NOT add backwards compatibility BACK INTO THE LANGUAGE?

      You know, like a COMPATIBILITY MODE ???

      can't be THAT hard...

      (or, is it MORE important to WIELD CONTROL and FORCE DEVELOPERS to "do things the new way" ???)

      WHY make the older code IN-compatible like this?

      I saw THIS which explains SOME of it... but it does NOT explain why there isn't a "backward compatible" setting of some kind.

      This seems to be one of those things that came about in the mid to late naughties, after which a bunch of VERY ARROGANT DEVELOPERS over the next few years just "DECIDED" - culminating in gnome 3, Australis, 2D FLATTY Windows 8, systemD, Pulse Audio, and of course the changes in Python 3 - they "JUST DECIDED" that ALL OF US MUST CHANGE and do things THEIR WAY!!!

      And of course, it *WAS* *RESISTED*, to the point of forking gnome 2 into Mate, creating Linux distros withOUT SystemD, and "forcing" the extension of the life of Python 2.7 ...

      maybe a FORK is in order? [are there enough people to support such a thing?]

      I don't do a lot of Python coding and so I may just deal with it and do things "the 3.x" way, but it might be nice to be able to write old-style code, which I had gotten used to, using a "compatibility" flag.

      1. Gene Cash Silver badge

        Re: lol

        Compatibility modes are always the wrong thing. The compatibility break is to get rid of cruft and bad features, not add more.

        Python 3 is basically where GvR said "ok, I made some mistakes designing things, but they're baked-in, so I can't change things without breaking compatibility" and eventually that was called Python 3.

        It was originally "Python 2000" which shows how long it was under discussion.

        I've done a ton of Python code, and it really isn't a big deal, and the changes are good ideas.

        Go back to talking about something you might know something about.

      2. Blackjack Silver badge

        Re: lol

        Because backtracks compatibility is one of the reasons Windows is such a mess?

        Windows is the biggest example of how backtracks compatibility can go wrong and I saying that as someone who uses a virtual version of Windows XP to run some games that I love and some programs I am so used to that I don't want to look for replacements.

        The two main problems with backtrack compatibility is people keeping using old stuff because it still works and new programs being made using old code because it still works.

        At some point you have to remove some backtrack compatibility and when you do you notice how a lot of stuff was still running old code, because you didn't force them to move on.

        That's one of the reasons why Microsoft had to offer Virtual Windows XP for Windows 7 Professional and Enterprise and why Windows XP got support for so long.

        The choice to not make Python 3 backwards compatible was the correct one.

        Come on guys you had since 2008, is not like Python is that hard, learn the new stuff and do new programs already!

        1. Anonymous Coward
          Anonymous Coward

          Re: lol

          I'm sure you're talking some sense, but backtracks? Seriously?

        2. jelabarre59 Silver badge

          Re: lol

          Because backtracks compatibility is one of the reasons Windows is such a mess?

          Windows is the biggest example of how backtracks compatibility can go wrong and I saying that as someone who uses a virtual version of Windows XP to run some games that I love and some programs I am so used to that I don't want to look for replacements.

          There's where I've thought MSWindows should just contribute all their old legacy code to Wine, and then just use Wine as a compatibility layer on top of a pared-down MSWin kernel/API. Old code is still supported, and the core gets cleaned up.

      3. TonyJ Silver badge

        Re: lol

        Jesus your unhinged use of capitals in random places in a sentence is starting to get even worse. What is actually wrong with just writing normally, like an adult?

  2. Henry Wertz 1 Gold badge

    Python breaking changes

    I worked on a project a while back that had some python3-incompatible code. The changes to make it python3-compatible were trivial, in the case of the code I was working on it was changing some print 'foo' with print('foo') . There's even a "compat" module to smooth over the few incompatibilities with the standard libraries; there's a handful of modules that were moved* between python2 and python3, or incompatible changes to the parameters passed in.

    1. Fruit and Nutcase Silver badge
      Joke

      Re: Python breaking changes

      The changes to make it python3-compatible were trivial, in the case of the code I was working on it was changing some print 'foo' with print('foo')

      Fast forward a decade or so...

      The changes to make it python4-compatible were trivial, in the case of the code I was working on it was changing block delimiting from indentation to use { }

      Note: Joke icon

      1. Dinanziame Bronze badge
        Trollface

        Re: Python breaking changes

        Why can't we have both? Like this for example

    2. Charlie Clark Silver badge

      Re: Python breaking changes

      Most code that runs on Python 2.7 will run on Python 3 without too much work. However, if you have C-extensions and other low-level stuff the amount of work required to migrate can be considerable. I know of a couple of libraries that won't make the change because of this. Though at the same time it should be noted that this also means that their user base has shrunk with time as other solutions become available.

      Then again, in many environments Python 2.7 can be expected to run reliably for many years, just as all the Cobol and Fortran code continues to do. Anything with public networking code is likely to struggle over time.

      1. Tom 38 Silver badge

        Re: Python breaking changes

        As the author of some python C extensions, the changes are surprisingly quite minimal. There are some differences with how modules are defined and initialised, which is handled with some #ifdefs, and you need to treat every string coming in to the python 2 library as though it is a python unicode object (converting it if it is not), define a few macros to normalize the API between the two, and then the string handling is the same on python 2 and 3 in your C code. Both things I mentioned here are about 20 lines of code in a common.h header, and maybe 15 lines of code in each python module you declare in C.

        Where an extension might have problems is if they have already written large parts of their code assuming that the strings coming in are actually byte strings, but for a new project targeting both versions I found it extremely easy to support both.

        C code in Python 3 is much simpler, because the strings API (which is the real big change between 2 and 3) is actually sensible. C extensions that find it difficult to deal with Python 3 are probably low quality, because they probably weren't dealing with strings properly in the first place (not a criticism, the API in 2 for unicode was haphazard, which is why there was the breaking changes to actually make Python 3).

        1. Charlie Clark Silver badge

          Re: Python breaking changes

          It's not all about strings and bytes. The work for some C extensions is not non-trivial because they're no good, because they'te non-trivial. At least so I've been told by a Python core developer… ;-)

          The switch would have been a real problem if the original Python 3 schedule had been maintained which placed the entire burden of migrating code on the developer: all downside with, at the time, no upside (slower, needs more memory). Fortunately, the PSF sponsored the migration of some popular libraries and frameworks and in the meantime, for the few projects that haven't made the change alternatives have become available: the large number of libraries as open source helping here. One notable example was pillow, the fork of PIL which Fredrik had abandoned.

    3. Anonymous Coward
      Anonymous Coward

      Re: Python breaking changes

      The changes to make it python3-compatible were trivial,

      Are you sure? There are some very nasty 'gotchas' in there which can break your code silently, such as the change to the way it does rounding:

      Python 2, round() is defined as:

      if two multiples are equally close, rounding is done away from 0 (so. for example, round(0.5) is 1.0 and round(-0.5) is -1.0)

      Python 3, round() is defined as:

      if two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2).

      A breaking change in a major version is sometimes unavoidable, but this sort of breakage is unforgiveable. At the very least they should have added a new round3() function for the new behaviour, and left existing code to behave as before.

      1. ibmalone Silver badge

        Re: Python breaking changes

        That's a rather strange one actually, since the most obvious numerical change (integer division promoted to float) seems intended more to produce the results non-programmers expect. (One of the fixes I've had to make to python2 code is going through and finding the divisions that are meant to be round-down-integer, a simple find and replace isn't going to be able to tell them apart from real number division, at least a general function change you can usually find the affected calls.)

        1. Charlie Clark Silver badge

          Re: Python breaking changes

          Those kind of gotchas require extensive tests. It then becomes a matter of importing the right feature from __future__ in Python 2 code, and fixing code so that tests run and knowing it will run with Python 3.

      2. Ogi
        Unhappy

        Re: Python breaking changes

        They also changed how they handle arithmetic division:

        Python2.7:

        >>> 2 / 3

        0

        Python3.5:

        >>> 2 / 3

        0.6666666666666666

        ---

        This caused horrible breakage on some software, because it did not throw an error, it just computed incorrect results. They should have had the interpreter print "Integer floor division warning at $line" (toggled by an interpreter flag perhaps?), as it would have helped me isolate and fix the issue.

        And then there is the string handling. Python2 was simple, and you did not have to worry about it too much. In python3 you have "bytes", and then "strings", and some things expect bytes, others expect strings, and you have to translate between them. The amount of hell I have had when porting things, having to decode/encode all over the place, is a real PITA. And it does not seem to have brought any real benefit to me, just a lot of headache and more code needing to be written for the same task as before.

        I've ported a few things across to python3, but if I am honest, some I ported to other languages, because it was easier.

        Overall I am not a fan of the changes to python3, some things are good, but overall they have made simple things harder and more obscure. Going forward I expect to be doing less and less Python work.

        1. ibmalone Silver badge

          Re: Python breaking changes

          I actually like the // and / combination, since it clarifies the operation expected (compare what happens in Python 2 when what you think is a floating point division unexpectedly becomes integer). It is a pain to retrofit, but that partly illustrates why it's useful.

      3. This post has been deleted by a moderator

        1. ibmalone Silver badge

          Re: Python breaking changes

          There isn't a 'correct' method of rounding, just conventions which offer different benefits. Most people wont even be aware of half-to-even.

          1. ibmalone Silver badge

            Re: Python breaking changes

            Given its subject, the symmetry of one up vote and one down vote on that post is beautiful. Please leave it exactly as it is and direct any further outrage to this post instead.

        2. Phil O'Sophical Silver badge

          Re: Python breaking changes

          This is not a "breaking" change, this is a "fixing" change.

          No, it breaks every application that depended on the old behaviour, even if they did so incorrectly. What's worse, it does it silently.

          1. Someone Else Silver badge

            Re: Python breaking changes

            "It's not a bug, it's a feature!!! 1

            You can go back to your Marketing office now, and leave all the "tecky" stuff to the professionals.

            1I actually worked at a place where that was the (unspoken) prime directive. Gad, talk about brittle code!

            1. ibmalone Silver badge

              Re: Python breaking changes

              Except it wasn't a bug, it was a documented and reasonable behaviour, now changed for another fairly reasonable, but different, behaviour.

  3. bazza Silver badge

    Repeat Offenders?

    Thing is, can the Pythonistas be trusted to not do this ever again? It’s been fairly off putting.

    I strongly suspect that the differences will continue to annoy for a long time to come. Somewhere or other someone will have some Python2 code running fulfilling a critical application that they never quite get round to updating, until it turns out to have been too late.

    1. amacater

      Re: Repeat Offenders?

      If they have Python 2 code running in a critical application that they never got round to updating - it is too late to "just leave it running" - it's been five years already since 2015 that the writings been on the wall.

    2. Dinanziame Bronze badge
      Meh

      Re: Repeat Offenders?

      As if C++ could be trusted to always compile with the newer version of the compiler

      1. TheMeerkat Bronze badge

        Re: Repeat Offenders?

        Java does.

        1. Dan 55 Silver badge

          Re: Repeat Offenders?

          Almost but not quite.

          1. Caspian Prince

            Re: Repeat Offenders?

            Mind you... still using Java code I wrote 20 years ago. Unmodified.

            1. Anonymous Coward
              Anonymous Coward

              Re: Repeat Offenders?

              Shudder! Sorry to hear that...

        2. sean.fr

          Java - not a good example

          It may compile but will it run on the client side?

          I have equipment that uses Java to provide the http/https user interferace. Newer browsers do not trust the obsolete plug-ins. I have other equipment that require recent Java. So it is never the right Java/browser.

      2. bombastic bob Silver badge
        Devil

        Re: Repeat Offenders?

        "As if C++ could be trusted to always compile with the newer version of the compiler"

        at least with the C++ compilers I work with you can specify whether or not the new language features should be implemented, i.e. "-std=c++14" for C++14 features

        making it similar for python - that'd be nice!

      3. bazza Silver badge

        Re: Repeat Offenders?

        Depends on how careful the coder has been to stick to standard C++. Use a library that’s outside of the standard, and all bets are off.

        Same goes for dependencies in other languages too. Python is no different.

      4. Someone Else Silver badge

        Re: Repeat Offenders?

        Was that a Microsoft compiler?

    3. bombastic bob Silver badge
      Thumb Up

      Re: Repeat Offenders?

      "can the Pythonistas be trusted to not do this ever again? It’s been fairly off putting."

      No. Good point.

    4. unccvince

      Re: Repeat Offenders?

      I had to use a few years ago a web application to post my social security contributions in France. I'm not technical but it it must have been javascript client based.

      On Internet Explorer, the amount I had to pay was XXX and on firefox it was YYY. I like Firefox better but YYY was bigger than XXX so I was not happy. I reported the problem to the IT team and I got a call the next day from the CIO thanking me for the finding.

      Conclusion of the story : there will be problems for some organisations transitioning from Python2 to Python3, their only option will be to to react quickly to their customers / users finding the issues that have slipped through testing, that's all.

      Imposed change is not a big deal if you can react quickly.

      Be safe, stay home and keep loving Python.

  4. Fruit and Nutcase Silver badge

    Come in Number 2, your time is up

    Python 2, 20 years

    Life expectancy of large Pythons... 20 or more years

  5. sean.fr

    why python ?

    I have see examples python scripts in Linux to do maintenance. Eg something called in a crontab to say rotate logs etc, or to backup a network device.. But I see more examples of perl glue, and perl is auto install in the distro.

    I can not see what python3 does that perl does not do. I cannot not see what python3 does that python2 does not do. I can see it is popular. But can someone explain why it is popular?. What was added over time that made a break necessary, What are its direct competitors?

    Note, I am not asking if it is any good - clearly some people think it is. There are much more books about it than say Visual Basic.I am trying to understand the design choices only. It seems to have features or lack features that you could expect in a modern language.

    GUI support seems light. Arrays are not a native data type. Parameters passing to functions seem be not exactly by value nor by reference. What are features that attract users?

    1. Paul Johnston

      Re: why python ?

      Critical mass is one of the main reasons I would say.

      As more people use it and the library support grows you have to move with the times for better or worse.

      For example if you want to use pymol you need python, end of story really.

    2. chuBb. Bronze badge

      Re: why python ?

      Same reason as php, free and millions of entry level articals to copy and paste from even if the canonical example are shown to be dangerously out of date, its easy for non programmers to pick up create gordian knots and be busy reinventing wheels.

      when all you have is a hammer everything looks like nails...

    3. Charlie Clark Silver badge

      Re: why python ?

      I can not see what python3 does that perl does not do.

      For system administration, probably nothing. But there are now many problem domains for which there are outstanding Python libraries: biology, statistics, engineering, etc. And of course, "machine learning" and "AI".

      And then, of course, the killer reason for many switching to Python: maintainability because readable. Sure, some people love their own perl code but hate others'…

      YMMV but I was just trying to answer the question.

    4. m4r35n357

      Re: why python ?

      For me - data plotting packages like Matplotlib and pi3d https://pi3d.github.io/html/ReadMe.html, previously the defunct Visual Python.

    5. Tom 38 Silver badge

      Re: why python ?

      python vs Perl: readability - Perl is often described as a "write only" language. OOP - at least in older versions of Perl, OOP is nasty. Less magic - use of punctuation in magic variables, these are all real things: $_, $), $/, $,, $|, $@ - there are more! Ecosystem - better libraries than CPAN. Isolatable environments - you can install an app with its packages, and not interfere with another app.

      Python 3: handles unicode sensibly. Python 2 had a very poor string/unicode divide, python 3 clearly delineates "these are a list of bytes" and "this is a string". You can't use a list of bytes where you need a string, without explicitly converting that list of bytes in to a string, and vice-versa. This leads to completely error-free text handling. Text handling is what python is good at.

      Arrays are very much a native type, they're called list(). It also has set(). Objects are always passed by reference, or the full truth - "object references are passed by value". If you call a function with an object, and then assign something to the name the original object was given inside your function, you're not reassigning the original object, you're assigning a new object to the name inside the function. In C terms, the functions are "foo(obj*)". You can't do a "foo(obj**)".

      Why do people like it? Its easy to read, its easy to write, it's easy to learn. There's a ton of libraries to integrate with, and they're generally easy to use too. Because of the big ecosystem, you can do a lot by writing a little. This appeals to people.

    6. LucreLout Silver badge

      Re: why python ?

      I can not see what python3 does that perl does not do. I cannot not see what python3 does that python2 does not do. I can see it is popular. But can someone explain why it is popular?

      I can sense the red arrows fueling and readying for flight, because this will be about as popular as a porn shoot in a nunnery.....

      Java is end of life. It just is. I know EOL has not been announced yet, but the 5 year plan for Java looks lacking in ambition even in comparison to the 5 year plan of my couch potato perennially single and unemployed mate Fat Matt. That, along with Oracles death grip on the spec, charges for the run time, and no money for investment (Oracle is in survival mode and Java isn't core to this), has made a lot of Java devs I know in finance very restless.

      These people have spent whole careers decrying Microsoft, despite the fact that dot net core is now transparently obviously the only sensible choice for LOB apps for the future. They're simply never going to move to it.

      So whats left, well, as you point out, perl or python. Perl is older than most developers, so they were never going to pick that, so python became the thing. I quite like it for simple automation scripts - I use it to manage a lot of my repetitive manager tasks. However, I wouldn't use it for proper applications that may need future proof scaling and other assorted stuff.

      Obviously there's javascript, but nobody in their right mind will let you run that serverside for anything requiring data security in finance - npm simply can't be trusted, and I've never yet met a single js dev that can credibly demonstrate how they validate security risks in package hierarchies thousand or tens of thousands of packages deep. It can't be done.

      Now, I expect a lot of Java devs and even some python devs to get rather emotional about all of this and downvote me to hell and back, but deep down, that's because they know I'm right.

      Apologies to the C++ folks for overlooking you thus far - you're your own special clan and irrelevant to many LOB apps that make up much of the industry - there's no debate when it comes to life critical stuff and a wealth of other app classifications.

      1. Anonymous Coward
        Anonymous Coward

        Re: because this will be about as popular as a porn shoot in a nunnery.....

        You underestimate the curiosity of bored people on pornhub,.

        1. Anonymous Coward
          Anonymous Coward

          Re: because this will be about as popular as a porn shoot in a nunnery.....

          I'm sure there's a hentai for that (likely more than one).

      2. Caspian Prince

        Re: why python ?

        Java is very much alive and well I think you'll find, particularly the JVM technology stack, but the language itself has been hugely rejuvenated. All greatly helped by Java mostly escaping the grasping tentacles of Oracle a few years back.

      3. amacater

        Re: why python ?

        So, so true. The "support" model for java is fundamentally broken at the moment and Oracle as a steward is essentially only hanging on in case there's big bucks due from the Google spat. NPM - it's a Lada car crash - you can see it waiting to happen at slow speed and the dependencies shear off like rust flakes. As for getting your software from a known repository ?? Doing any kind of information assurance/software management on newer languages - you're doomed to fail.

      4. Anonymous Coward
        Anonymous Coward

        Re: why python ?

        I see you dont get out much. And live in a very very tiny programming universe. You must have got your start in VB by the sound of it..

        All you need to know about dot.net core is that although its been a while since I worked on a dev team with some of the former dot.net team from Across The Lake in Redmond nothing would get a bigger hollow cynical laugh from those folk than to suggest using dot net for anything that you wanted to ship as a viable stable commercial product. Of course for people who live in the self contained universe of in house developed software any old crap will do, and generally has for the last forty odd years I have been familiar with that particular world.

        Been using Python for writing casual dev tools for about 20 years. Great for doing this. Less fiddly than Tk/TCL. Never bothered upgrading to Python 3 for lots of reasons, the main one being that anyone stupid enough to break backward compatibility for purely arbitrary reasons cannot really be trusted with other decisions either. Sounds too much like Second Version Syndrome. Give me opportunistic pragmatism any day when it comes to design decisions in languages and IDEs that I will use and trust. Like Python 2.x.

        1. sean.fr

          Not ashamed of Basic

          While not my first langage, it was the first that did not involve paper tape or cards and a long wait for batch processing .Dartmouth Basic on a terminal. A whole generation of British people learnt BASIC on BBC micro in school. I have fond memories of Basic on a Z81, Tiny Basic in 4K on the processor chip, BBC Basic and Basic in Excel. I loved Visual Basic and the BASIC family in general.

          1. LucreLout Silver badge

            Re: Not ashamed of Basic

            Not ashamed of Basic

            Quite - first languages I learned were flavours of BASIC too. It's easy to read, easy to write, and there's loads of it out there to help you get going. The irony of a Python dev decrying basic seems utterly lost on him, when those are three of the reasons he gives for liking Python.

            I'm teaching my 6 year old to code at the moment using Python precisely because its this millenniums version of BASIC. Perhaps if the AC got out more he'd see it for himself....

    7. Ogi

      Re: why python ?

      I can not see what python3 does that perl does not do. I cannot not see what python3 does that python2 does not do. I can see it is popular. But can someone explain why it is popular?. What was added over time that made a break necessary, What are its direct competitors?

      In my opinion, Python became popular because it was easy to copy and paste from others code. Which made it easier for "newbies" to program.

      Case in point. Back in the turn of the millennium (2000 or so), I wanted to learn to code on Linux. I was still at school and could not afford windows compilers. I could not get my head around C, so I looked at the two main options at the time. Perl was the established player, and this upstart called "Python" had just reached version 2.0.

      Logically I went with perl, as it was the most popular, and tried to cobble stuff together the only way I knew, by copy pasting other code I found online, and trying to understand how it worked. Problem is, it just would not work, I would get syntax errors, or other errors, or it just would give incorrect results. I would look for "how to do $x" online and get 20 different ways of doing it, it was overwhelming, and I eventually gave up and tried Python.

      Python was different, there is "only one way to do it", which meant I could copy/paste code from different projects and it would work, I could search "how to do $x" and get one overwhelmingly "correct" answer, which worked, and once I understood what a piece of code did, when I read other peoples code I could understand what they were doing.

      Python is what got me deep into programming, and indeed I do believe this was one of the reasons many "educational" projects for young children seem to start with Python (or Python-like) programming languages. It is literally the "Basic" of Linux. Nowadays you can code up a python program to do what you want just by copy/pasting from stackoverflow (not that I would recommend it for anything serious, but for newbies it is useful)

      Now, 20 years later, I still code in Python, but less and less scripting. The flexibility and string mangling of perl beats python hands down, while for performance I prefer C. Python sits in an interesting niche, I guess roughly where Java does, as kind of "middleware", and also it has some very good libraries for statistical analysis (the "jupyter" notebooks with numpy, pyplot and stats libraries has no equal for the price).

      As for the changes between 2 and 3, the only one I was ok with was the conversion of "print" from a statement to a function, beyond that the changes either made no difference to me, or made my life harder, so meh.

      1. ibmalone Silver badge

        Re: why python ?

        Yes, Perl I still find better for general glue programming, largely because of its string handling, it's built for executing things and interpreting the output, no other language really is. Despite its reputation it's possible to write clean and readable Perl, you just have to avoid the temptation to use its implicit tricks too much.

        On the other hand, Python library support is excellent, and it makes prototyping a lot easier than compiled languages; if I want to get an image and Fourier transform it in C I need quite a bit of boilerplate to use functions and structures from two libraries and then probably do some format munging to shovel from one to the other. In Python the slightly larger set of built in types and standardisation on numpy for numerical work makes it trivial, and if you know how to make good use of the underlying compiled libraries (e.g. numpy's tensor products) you can write things that compete with compiled code for speed (been meaning to look at Cython, but numpy is sufficiently good that it's not been worth it yet). It's not going to take over from C for really high performance stuff, all those handy types come with a cost, but sometimes development and prototyping time are more important (and I suspect to really be efficient it's worth taking the time to write the bits that need to be fast as C and wrap them up in python for the convenience).

        1. Charlie Clark Silver badge

          Re: why python ?

          IIRC I think there are bits of Numpy that offload the calculations to Fortran libraries, which make C look positively slow. But it could be another part of the Python stack. It's certainly not uncommon for Fortran (and C and C++) libaries be wrapped and exposed for use in Python, I know that CERN does this for some the LHC work. Python really excels at this kind of task meaning that the mathematical geniuses write the code that normal scientists without Comp Sci or Maths PhDs get to call from Python. Meaning that stuff is both fast and safe.

  6. scottyman

    I thought I had successfully scrubbed all traces of Python 2.7 off my machine - the lo and behold - I installed an update to Node.js and one of the XML dependencies decided that it really did need Python 2 not Python 3

  7. Anonymous Coward
    Anonymous Coward

    Sync -> async in Py3 is way harder than Py2 -> Py3

    Way, way harder. The async keyword in python spreads like Covid.

    1. karlkarl Silver badge

      Re: Sync -> async in Py3 is way harder than Py2 -> Py3

      So true!

      Async is becoming a real problem. More and more libraries are using async facilities in their public API (I don't care what they do internally) and that is forcing us to look for alternatives.

      Unfortunately this is for our C++ projects too. Even that language isn't immune to terrible callback designs.

      1. Maximum Delfango Bronze badge

        Re: Sync -> async in Py3 is way harder than Py2 -> Py3

        In Python it's daft that the sync -> async barrier is so absolute. A really, really bad bit of design.

        1. Maximum Delfango Bronze badge
          Thumb Up

          Re: Sync -> async in Py3 is way harder than Py2 -> Py3

          Thumb down! GvanR reads the Register!

    2. Charlie Clark Silver badge

      Re: Sync -> async in Py3 is way harder than Py2 -> Py3

      I think this is a sign that's it not really ready for general adoption yet. It has got much better but, most of the time, most of us aren't going to need it.

      1. Maximum Delfango Bronze badge

        Re: Sync -> async in Py3 is way harder than Py2 -> Py3

        See Trio for how it should've been done.

        1. Charlie Clark Silver badge

          Re: Sync -> async in Py3 is way harder than Py2 -> Py3

          My understanding is that some of the Trio stuff has been included. But I think this is also par for the course for making such substantive changes to the language. You start with an implementation as specification and work with the feedback. This has been the case for several important features in Python.

          I remember that when yield was introduced as a keyword that I really struggled with the generators and would have preferred a different keyword for generators, which is sort of where we're at at the moment. At some point I think the runtime will be good enough to decide when some code is to run asynchronously or not but in the meantime a parallel stack is probably unavoidable.

  8. Anonymous Coward
    Anonymous Coward

    Carrying on with the theme of obsolete languages that have been flavour of the month recently... COBOL... Businesses and Organisations that aren't prepared to migrate old stuff to current platforms deserve to break. And there will be an orderly queue of consultants eager to offer services to prop up those old ailing systems.

    Cost-benefit analysis in the short term might say hire the consultant, but on any other timescale, the proper thing to do is get it refactored and upgraded already!

    1. Anonymous Coward
      Anonymous Coward

      Obsolete?

      I'm going hard-core 'obsolete': I'm about to dive back into Z80 machine code. Haven't done that since the mid 1980s. Standby, I'm going in...

    2. Dwarf Silver badge

      @binraider666

      The challenge there is that the bean counters can't see beyond the end of the current quarter, so they never see common sense.

      Its a bit like having a pilot that only looks beyond the end of the nose cone of their plane or the driver that can't see beyond the next 10 metres. Its all common sense when applies to real worlds, but for bean counters, nope, no way, put it off till next quarter and hide under a rock and hope it doesn't happen and try to get a good personal bonus next quarter.

    3. Charlie Clark Silver badge

      I'm pretty certain that as soon as it became possible to virtualise architectures, it became cheaper not to migrate code bases. Rewriting a lot of the code written in the 1960s, 1970s and 1980s is simply not an option. The solution is virtualise and replace when required.

      1. Anonymous Coward
        Anonymous Coward

        And this is why we have a long, long catalogue of high profile IT failures associated with legacy tech persisting way beyond it's use-by date. Natwest, Saudi Aramco to name two really obvious and very expensive cases. Not hard to find others.

        Those whose only objective is to survive long enough to move onto the next job? Well, companies that exhibit those behaviours are precisely the ones that I won't score highly on tender events.

  9. GBE

    I still miss fixed-lenght integers

    Yeesh, I feel old. I still sometimes miss the fixed-length integer math from Python 1.5.

  10. Drew Scriver Silver badge
    Pint

    We'll be forced to support 2.7 for at least another decade...

    I can't even begin to recount all the instances where I've seen companies force Ops to support old versions rather than to tell Dev to upgrade...

    On a funny side note, once I started adding the prefix "kludge" to my workaround projects/solutions things tended to change. The developers didn't want that kind of exposure and management was embarrassed. Imagine the CEO asking, "What's a kludge?"

    Their first solution was to see if I could be pressured into dropping the term "kludge". When that didn't work they actually fixed the majority of the root problems.

    1. Anonymous Coward
      Anonymous Coward

      Re: We'll be forced to support 2.7 for at least another decade...

      You'll be 'furloughed' pretty soon now, I expect.

  11. Anonymous Coward
    Anonymous Coward

    Is that last line a common phrase or a Detectorists (mis)quote ?

  12. robert lindsay
    Mushroom

    joy

    we dont even HAVE python 3 installed on half our systems...

  13. streaky

    The only surprise here..

    .. is that there are no major Py2 forks yet.. Py3 aint happening any time soon, sorry lads.

    1. Charlie Clark Silver badge

      Re: The only surprise here..

      Both Google and Dropbox made them. Google's was famously known as "unladen swallow" but I think they then shifted to Go for the stuff they were going to use it for. Dropbox pushed MyPy which ended up force-feeding type hints into Python. Some people have backported some stuff to Python 2 but I don't think there's anyone now seriously interested in actively developing a fork. It took a long time but Python 3 is now better for most situations.

  14. Anonymous Coward
    Anonymous Coward

    I f*****g love Python!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020