Hacker News Reader

Comment by Godel_unicode | Hacker News Reader

Reminder that Python 2 dies in 18 months.

It will likely remain around for longer, since depending on unsupported software doesn't immediately kill a project. When old Python 2 code hits a bug in the CPython interpreter and nobody is around to fix it, there'll finally be an incentive to migrate away (maybe to Python 3, maybe to another language), but not before that.

True, however lots of large corporates won't use an unsupported version if the vendor drops it.

There, the vendor will be redhat or ... who will be supporting it longer. What enterprises mean by support isn't provided by the PSF anyway.

They support their products 10 years, or indefinitely if you pay extra for it, so Redhat will support Python 2 until June 30, 2024.

If I understand it correctly, that means CentOS will too.

> It will likely remain around for longer, since depending on unsupported software doesn't immediately kill a project.

It also depends on how long companies like Redhat support it (CentOS 6 comes with Python 2.6 and CentOS 7 comes with Python 2.7).

The PSF might be trying to murder Python 2, but it can't do it any more than GCC could kill c99 for c11.

I look forward to using c99 and Python 2.7 for many years to come. There are more then enough Companies and Devs to keep Python 2 ticking over forever.

GCC and clang are probably the only C compilers in the world that care about C11, so it is quite hard to kill C99 for C11.

Last I checked MSVC couldn't even do C99 properly yet.

Because it is called Visual C++ and Microsoft has openly stated that they are compliant to the extent required by ISO C++, which is the future of systems programming on Windows, alongside .NET Native for some use cases.

ISO C++14 requires C99 library compatibility, ISO C++17 requires C11 library compatibility only when C++ doesn't already offer better alternatives.

For C developers there is clang/gcc integration in Visual Studio.

"Modern C++ Game Development on Microsoft Platforms"

https://www.youtube.com/watch?v=on8HMZdAXaw

True, but following the Python model, GCC and Clang could just threaten people with the death of C99 for 5 years or so, then in some release just disable them.

Of course, that would be much less painful than Python 3, because C11 is (a) almost entirely compatible with C99, and (b) not noticeably slower.

I was given to understand that Python 3 got past after 3.5 or so?

Not only did it get faster as a drop in replacement (assuming you thought ahead at all sometime in the last 10 years), but if you can make use of the new async keywords you can get much faster code after a slight refactor.

AFAIK python 3.5 and 3.6 are significantly faster than 2.7 and uses less memory due to dictionary optimizations. I don’t think speed has been a real argument in a while. Also, python 3 is almost entirely compatible with python 2 (although C is probably even more so).

Everyone would have migrated to python 3 years ago if it was almost entirely compatible with python 2. It's just not.

C and Python's compatibility aren't comparable.

It's quite hard to write a C89 program that isn't C99. Basically any Python 2 program that uses 'print' won't be valid Python 3. Even after fixing that, I always find a bunch of string related problems.

C99 is a language standard. Python 2 is a language and the CPython runtime, and a massive standard library. They're barely comparable.

What it certainly true is that it will take exponentially more work to keep Python 2 alive. They're not allowed to use the name so that's an instant usage drop-off. And many major third party libraries are dropping support too.

You're probably right though. You'll probably get to use Pytwo (or whatever they call its) for a few more years yet.

But.... Why?

My reaction as well. I understand continuing to build something already written in 2.7. However, building new with 2.7 just seems contrarian.

My problem is I'm rarely building something new -- I have various libraries and utilities in python 2, and will extend and use them in my research, along with coauthors in other universities. Therefore, having a "big bang" change to Python 3 is very difficult.

In practice I imagine some day some PhD student will take it upon themselves to rewrite a significant chunk of libraries to be python 3 compatible, and then we could move on from there, but I wouldnt want to force anyone to spend the time doing a massive Python 3 rewrite.

I'm curious whether you've looked at __future__ and libraries like six? I've found it quite easy to write Python 2/3 compatible code with them and a little planning. I like this approach to maintenance of legacy libraries as it at least prevents making the problem worse.

I wouldn't be surprised that vendors will still have to do the fixes to Python 2 for many years past that date, and that a kind of "fork" will keep the 2.7 branch decently alive much longer. It's just the current "official" maintainers that announce the cutoff date for their work.

Another problem is 'semi-abandoned' code. For example the Open Source program QGIS used to use Python2 is its main plug in language but recently switched to Python3. The end result is the most plug-ins don't work any more. And since many of the plug-ins where useful little niche scripts that someone wrote years ago and then stopped updating/supporting once they where done, the chance that most of them will see a port is tiny.

Doesn't mean that python 2 programs will stop working. I know developer of Calibre has stated that he will maintain the python 2 codebase himself. And is actually happy that python 2 development will be out of the current maintainers hands.

That's insanity. I love Calibre, but under-the-hood it's spaghetti.

Calibre is more than a decade worth of his development time. Maintaining python 2.7 for calibre would take a magnitude of less developer time and resources than porting calibre to python 3.

Reply on news.ycombinator.com