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

391–400 of 733 posts

Re: Sunsetting Python 2

#391

Post by dangxiaopin »

AlphaSite wrote: post #385
dangxiaopin wrote: post #374

I think the sunsetting is very premature. Python 3 became a stable and viable alternative only since 3.6.1 (look at the evolution of async/await before that for example). Giving it 2 years is definitely not enough for enterprise (unless their focus is startup, tinkerers and data scientists)

I mean, arguably they’ve been telling you too move for far longer. So it seems reasonable to sunset it after 10 years.

So migrate a large production codebase to unstable API? With dependencies not yet migrated?

Re: Sunsetting Python 2

#392

Post by Crinus »

koreth1 wrote: post #282
ueiuestu wrote: post #260

Earlier quoted context omitted.

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

I would have said Java, but then they decided to shove modules down everyone's throat.

Wouldn't Java 1.0 code still work in Java $LATEST even with modules? As i understand it the question was about keeping stuff working, not refusing to add new stuff.

Re: Sunsetting Python 2

#393

Post by tempsolution »

Wow that is some bad management. For 15 years they say nothing and then they give a whole half year for people to migrate. The reason why people did not migrate is because it is a huge effort and as long as python 2 still is being developed, why bother?

The right thing to do would have been to immediately deprecate python 2, only supply security fixes and tell them in 2010 or so that support will run out in 2015 or, well 2020. But this is just crazy.

Re: Sunsetting Python 2

#394

Post by pudquick »

salamanderman wrote: post #304

My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that kind of subtle defaults that I think slowed the transition. I didn't want to change the system Python.

In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time.

I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.

Re: Sunsetting Python 2

#395

Post by inatreecrown2 »

ken wrote: post #240

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…

you are comparing an open source language to the apple os.

Re: Sunsetting Python 2

#396

Post by normalhuman »

gmfawcett wrote: post #388
normalhuman wrote: post #361

Earlier quoted context omitted.

Corparate-speak that makes its way into common language is frequently justified post-hoc by subtle differences in meaning like the ones you allude to. The problem is that these differences are personal and subjective. Ask someone else, they might have a different answer. I have had the same discussion multiple times over the equally meaningless and inelegant "going forward". "Use case" comes from 90s software enginee…

You're picking much too fine a nit here. The OP's use of "personal use case" is not a distracting example of corporate speak. I knew exactly what he meant when he wrote it, and his usage did help to clarify that he was basing his statements on his use of the technology, and not on his personal feelings about it. But if if this is a hard-stop item for you at this juncture, then we should circle back... I'm sure we can…

> You're picking much too fine a nit here.

I think you feel that way because of the HN/tech echo chamber. Nobody says or feels the need to say "use case" outside of such circles.

> But if if this is a hard-stop item for you at this juncture, then we should circle back... I'm sure we can align on this going forward. ;)

Hehe ;)

Re: Sunsetting Python 2

#397

Post by gvb »

Yhippa wrote: post #380
Lt_Riza_Hawkeye wrote: post #370

Earlier quoted context omitted.

>Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively develope…

I'm on the outside looking in but practically speaking, why couldn't I "just use Python 3" then for everything?

Python 2 and 3 are different compiler/interpreters. Python 2 code might run on a Python 3 interpreter, but probably not. When you run your python2 code, you can specify that it is to run on the Python 2 compiler/interpreter. The Python 2 compiler/interpreter will continue to run and thus be able to run python2 code for a very long time.

Ubuntu 18.04 example:

    $ python --version
    Python 2.7.15+

    $ python2 --version
    Python 2.7.15+

    $ python3 --version
    Python 3.6.8

    $ ls -l /usr/bin/python
    lrwxrwxrwx 1 root root 9 Apr 16  2018 /usr/bin/python -> python2.7

Re: Sunsetting Python 2

#398

Post by jedberg »

normalhuman wrote: post #235
jedberg wrote: post #62

In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…

> For my personal use case at least, this timeline worked out well for me. Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't. In this case, you could say "This timeline worked out well for me".

I used "use case" specifically because I was referring to business use cases.

Re: Sunsetting Python 2

#399

Post by normalhuman »

meowface wrote: post #377
normalhuman wrote: post #361

Earlier quoted context omitted.

Corparate-speak that makes its way into common language is frequently justified post-hoc by subtle differences in meaning like the ones you allude to. The problem is that these differences are personal and subjective. Ask someone else, they might have a different answer. I have had the same discussion multiple times over the equally meaningless and inelegant "going forward". "Use case" comes from 90s software enginee…

This seems extremely pedantic. "Use case" as it's used today basically just means "case" or "situation" for a particular project or task or goal (edit: and for a particular individual/group/entity/organization). It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago. I can think of countless annoying corporate buzzwords I see all the time on HN or at my job which are tot…

> This seems extremely pedantic. "Use case" as it's used today basically just means "case" or "situation" for a particular project or task or goal. It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago.

Notice that you are already in contradiction with the first criticism that I received in this thread, where a subtle difference in meaning was proposed.

> it means "in the future", which is ambiguous, but it's no more ambiguous than saying "in the future",

The main point is that it is totally unnecessary, we already have the future tense to talk about what will happen in the future.

The same applies here. Remove the phrase with "use case" and you get exactly the same meaning, with less words and less cringe.

Re: Sunsetting Python 2

#400

Post by ilikehurdles »

Kaiyou wrote: post #360
ilikehurdles wrote: post #286

Earlier quoted context omitted.

You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate. At no point do you have to wait on anyone else, you choose to .

You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.

If there is significant demand for solving the problem your fork solves, others will migrate to it. This is made harder when the main solution gets to squeak along for 10 extra years on a version of the language that should no longer get first-party support. Of course there is going to be less demand for that Py3 solution when there is no immediate consequence for continuing on Py2. Killing security update support for 2 will boost the demand for libraries using 3, and make it more likely that your fork gets merged or becomes the defacto standard.

The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.

Post reply on HN