Live data from Hacker News

Sunsetting Python 2

python.org

501–510 of 733 posts

Re: Sunsetting Python 2

#501
post #67
post #7

Some shared hosting providers are still offering Python 2.6 as their main offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version. [1] https://www.hostgator.com/help/article/what-software-and-pro...

I was Googling “HostGator Python 3” and found you said the same thing last year on HN: https://news.ycombinator.com/item?id=16808998 We knew in April 2014 that Python 2 was EOL in 2020.

Yes, I was hoping for some progress at HostGator so I could get rid of the last Python 2.x I have running. But I can't, yet.

Re: Sunsetting Python 2

#502
post #165

Earlier quoted context omitted.

You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.

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.

I often hear this, but I just don't see this working in practice. A very similar example I have experience with, I've often worked with people who tried to write code that would be "compatible with Windows" (I primary work in a Linux environment). It makes the code more difficult to read and as soon as you try and run it in Windows it fails spectacularly.

You can write code that's compatible with both Python 2 and 3, but I don't think you can expect to be using Python 2 exclusively and write code that works well in Python 3 unless you're constantly running it with Python 3. Especially, if you don't have much firsthand Python 3 experience. This is much easier if your code is isolated from those dependencies and you write tests that run in both Python 2 and 3, but that's quite a bit more of a commitment than you seem to be implying.

Re: Sunsetting Python 2

#503

Earlier quoted context omitted.

Yes, those people are arrogant and/or entitled, but you know darn well that's not the arrogance GP was talking about. It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet. As choppaface said, > Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback. If Python 3 could run P…

> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet. That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?

First,

> why don't you cough up the cash?

I am.

Second,

> "decide to no longer volunteer their own time."

If that's all they were saying I would STFU.

They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are still using it.

Re: Sunsetting Python 2

#504

Earlier quoted context omitted.

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 ;)

I dunno -- if we're going to focus on the tics and quirks of the HN echo chamber, isn't this level of bikeshedding over the term "use case" kind of peak HN? :)

Re: Sunsetting Python 2

#505
post #331

Earlier quoted context omitted.

Python 3.1 came out 10 years ago. 3.2 was released in 2011. What does that mean about the complaints since, let’s just say 2015 to be fair?

I heard several people saying that 3.6 was the first Py3 worth transitioning to. Largely for async (I think async/await came to live then). There is this take on performance: https://hackernoon.com/which-is-the-fastest-version-of-pytho...

Ordered dicts and f-strings are also very sweet!

Re: Sunsetting Python 2

#506

Earlier quoted context omitted.

Calibre is another well known case, and they don't plan to migrate. Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are…

That's not true. https://github.com/kovidgoyal/calibre/blob/master/README.pyt... https://github.com/kovidgoyal/calibre/pull/870

If that's the case, I'm glad to see things are changing. Up until very recently, there seem to have been no plans to switch: https://bugs.launchpad.net/calibre/+bug/1714107

> No, it doesn't [need to convert to Python 3]. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.

Re: Sunsetting Python 2

#507

Earlier quoted context omitted.

> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet. That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?

First, > why don't you cough up the cash? I am. Second, > "decide to no longer volunteer their own time." If that's all they were saying I would STFU. They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are s…

Making them use a name other than python is hardly any great hardship. Mozilla maintains their trademark too and nobody whines to hard about that. Just call it "boa" or something. Firefox->Icecat.

Re: Sunsetting Python 2

#508
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…

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy.

It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors.

The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !).

But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix.

The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about.

Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing.

Nonetheless, the screams from the first ones scared the later.

Re: Sunsetting Python 2

#509
Wow. I still found some inadequacies with six, such as support for bytes/b, datetime (timestamp) and SimpleHttpServer

Overall, didn't have too many issues with the conversion but this stuff is going to hit some companies harder than others. I can tell that it's worth the migration, end this blood fest once and for all.

Re: Sunsetting Python 2

#510
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…

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…

“unless there are reasons the porting is difficult, it’s easy”

thanks, chief. genius stuff there

Post reply on HN