Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

191–200 of 733 posts

Re: Sunsetting Python 2

#191

Post by hobofan »

SiempreViernes wrote: post #157
hobofan wrote: post #147

Earlier quoted context omitted.

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

A lot of libraries refused to migrate before Python 3.5(?) came out which was ~4 years ago. IIRC earlier Python 3 versions had performance regressions compared to Python 2.

Re: Sunsetting Python 2

#192

Post by toyg »

jsjohnst wrote: post #168
toyg wrote: post #120

Earlier quoted context omitted.

Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?

> Because you can’t bear the use of parentheses for print, really? While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.

You are right. I'm probably still shellshocked by the initial wave of complaints, so many years ago...

Re: Sunsetting Python 2

#194

Post by aequitas »

unionpivo wrote: post #41
d--b wrote: post #18

Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).

thats the worst kind of limbo, sort of supported and official but not really. I fully support them in this. Either you support it right, or you abandon/sunset it clearly. If someone else wants to step up and do the work, they can always do that on their own.

Indeed, plus people will still come knocking at their door for Python 2 issues. And if you tell them to contact someone else for support people will still be upset. Imho communicating EOL is the only way to go. Others can pick up legacy support under a different name. People will find them and it will be clear it's a different team.

Re: Sunsetting Python 2

#195

Post by aaron695 »

Is there a list of Open Source that needs converting?

The first obvious one to me to check found this -

> Bug Description Python 2 is retiring in thirty months. Calibre needs to convert to Python 3.

> No, it doesn't. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.

https://bugs.launchpad.net/calibre/+bug/1714107

Re: Sunsetting Python 2

#196

Post by sixothree »

drej wrote: post #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 t…

HL7.org has a banner on every version of the FHIR spec with a different message depending on the version. http://hl7.org/fhir/

Re: Sunsetting Python 2

#198

Post by op00to »

drej wrote: post #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 t…

I’m confused here - do you think anyone sophisticated enough to worry about the supportability of a language is also dense enough to realize Python 2 is EOL? A banner is fine for unfrozen cavemen coders, I guess.

Re: Sunsetting Python 2

#199

Post by toyg »

charlus wrote: post #193

Given we'll be at Python 3.8 next month, I can't help but wonder about Python 4. When it will happen, and how long.

All indications are that we'll see 3.10 before 4 is considered.

I think it would probably be ok to start thinking about it in a year or two from the py2 sunset. It will be a minor update anyway, it's just a PR exercise that can be done whenever people think it would be more effective.

Re: Sunsetting Python 2

#200

Post by ericvsmith »

mehrdadn wrote: post #190
ensignavenger wrote: post #180

Earlier quoted context omitted.

But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.

> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...

> This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...

While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3.

[Edit: gas -> gasoline]

Post reply on HN