There's no reason you can't be part of the equivalent population for Python.

Very few people still program in 77 and only if they really have to. Everybody who has a choice has moved on to at least Fortran 90 and you won't find anybody seriously arguing that Fortran 90 isn't a massive improvement over 77.

I believe that many of not most Python 3.5 users consider it a massive improvement over Python 2.7. My examples come from the core developers, so is highly suspect to bias.

That's because you can compile Fortran 77 with a modern Fortran compiler and link the old code into your new one without a lot of work.

On the other hand I fail to see how you could use the Pyhton 3 interpreter with some old incompatible Pyhton library.

Some answers are: it's faster, it runs on new OSes, it has better error messages.

Those then become the same answers to the OP's question about shifting from Python 2.x to 3.x.

While with Pyhton 2 to Python 3 there is usually a non trivial amount of work you need to put into migrating an old codebase.

You're siding with a shrinking ecosystem (Python 2) over a growing ecosystem. Depending on your use case, this could range from inconsequential to inconvenient to disastrous.

If you have an existing codebase in Python 2, then perhaps the conversion to 3 isn't worth the effort. But if you're developing new software, the question is why not make the minimal investment to make your work compatible with the future of the language? When I see a new library and the author couldn't be bothered to adopt Python 3, it's a big red flag.

Couple that with 2.7 being good enough just makes the situation "worse" for 3.

Also that's kind of what this post is about. Pretty soon there'll be a bigger risk of finding that some library you want is Python3-only than finding that some library you want is Python2-only.

Probably because of the ecosystem. And that will be when everyone transitions to Py3, when stuff they want to use is Py3 only.

This always bugged me about Python:

    >>> exit
    Use exit() or Ctrl-D (i.e. EOF) to exit

    >>> range 4
    Traceback (most recent call last):
      File "python", line 1
        range 4
              ^
    SyntaxError: unexpected EOF while parsing

    >>> print 4
    Traceback (most recent call last):
      File "python", line 1
        print 4
              ^
    SyntaxError: Missing parentheses in call to 'print'

    //rant

    >>> exit
    Use exit() or Ctrl-D (i.e. EOF) to exit

Python has no idea that's what you mean.

    >>> repr(exit)
    'Use exit() or Ctrl-D (i.e. EOF) to exit'

    >>> print 4
    SyntaxError: Missing parentheses in call to 'print'

Meanwhile...

    #include<stdio.h>
    
    int main(void) {
        printf "Hello World\n";
        return 0;
    }

    hello.c:4:9: error: expected ';' after expression
      printf "Hello World\n";
            ^
            ;
    hello.c:4:3: warning: expression result unused [-Wunused-value]
      printf "Hello World\n";
      ^~~~~~
    hello.c:4:10: warning: expression result unused [-Wunused-value]
      printf "Hello World\n";
             ^~~~~~~~~~~~~~~
    2 warnings and 1 error generated.

Sorry I hit a nerve. You insisted it 'wasn't the same' but didn't give an example.

If you don't need what Py2 provides, I don't know why it wouldn't be 'good enough'. And since I built a lot of complex stuff in Py1, I can't imagine why anyone would think it is not good enough for building complex stuff.

1. I got used to it, fairly quickly. That made me care less.

2. I used print-statement debugging less, and unit tests more. This was a good thing generally.

3. For those times when I did need print to debug, I found I could drop in pprint:

    import pprint
    print = pprint.pprint

I've rarely needed naked print to do anything but quick testing and debugging (because by the time I have a command line script, I want at least to have a -q option, so I need to run output through some kind of proxy function). The standard arguments for print() (i.e. composability, extra arguments), I've not needed, but the ability to replace it, I rely on totally now.

Of course, YMMV, this is just my experience.

print isn't a statement in python 3 and range was never a statement

Additionally, eventually new libraries will also stop supporting 2.7, with the same issues as well as making development harder (or not as easy as your peers/competitors)