Live data from Hacker News

Sunsetting Python 2

python.org

151–160 of 733 posts

Re: Sunsetting Python 2

#151
Kill it with fire!

Should have been removed years ago.

It actually causes real issues, such as build systems that only support python2 but not python3.

The sooner python2 dies, the better. I need to use both python2 and python3 since otherwise quite several software projects refuse to compile from source. An example is Mozilla's mozjs.

http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h...

Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite. Total clowns working at Mozilla here.

Re: Sunsetting Python 2

#152

Earlier quoted context omitted.

The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.

> porting our library Library, as is most open source libraries out there, sure. For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.

You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when the deadline was postponed by 5(!) years.

Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.

Re: Sunsetting Python 2

#153

One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.

Why would anyone like python2 so much better than python3 that they would want to fork it into its own language? The two languages are already incredibly similar and python3 has a much larger active community.

Because I have 20-year-old code in the wild still running. I know python won't change out from under me; I do not have that confidence in python3.

Re: Sunsetting Python 2

#154
post #3

> If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team i…

Exactly! I am getting tired of FOSS orgs thinking they can speak for their entire extended community.

`PSF` should be inserted before every occurance of the word volunteer in that page.

Re: Sunsetting Python 2

#155
post #70
post #61

So they are sun-setting it 12 years after having introduced its replacement. I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.

.Net 5 will be reuniting the brands (Though based on .net core). So the Core brand will be discontinued. Read more about it here: https://devblogs.microsoft.com/dotnet/net-core-is-the-future...

They're changing the branding ... AGAIN?!

Re: Sunsetting Python 2

#156

Kill it with fire! Should have been removed years ago. It actually causes real issues, such as build systems that only support python2 but not python3. The sooner python2 dies, the better. I need to use both python2 and python3 since otherwise quite several software projects refuse to compile from source. An example is Mozilla's mozjs. http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h... Also increases you…

> Total clowns working at Mozilla here.

Was the cheap shot really necessary?

Re: Sunsetting Python 2

#157

Earlier quoted context omitted.

The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.

> porting our library Library, as is most open source libraries out there, sure. For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.

The time frame is 12 years though, since the sunset was originally announced in 2008.

Re: Sunsetting Python 2

#158
post #121

"What will happen if I do not upgrade by January 1st, 2020?" "You will lose chances to use good tools because they will only run on Python 3, you will slow down people who depend on you and work with you." The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right…

Did we read the same document? It seems fine and a perfectly normal explanation of what’s going on and why, like any software with a defined lifecycle would have.

I guess it depends what lens you are reading it through. If you're used to reading documents from open source projects it seems perfectly normal. If you're used reading documents from Oracle and SAP explaining changes to their long term support contract, then this will sound completely alien.

Re: Sunsetting Python 2

#159
What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html

Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html

Are there plans to add a banner to Python 2's docs? I think it would be quite instructive.

Re: Sunsetting Python 2

#160

Earlier quoted context omitted.

Not really. :-) ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.

Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled. C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing…

That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is.
Post reply on HN