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

331–340 of 733 posts

Re: Sunsetting Python 2

#331

Post by dahart »

lvh wrote: post #268
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…

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…

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?

Re: Sunsetting Python 2

#332

Post by weberc2 »

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

Driving an EV without charging stations is (nearly) useless. You can still run Python 2-3 code with a Python 2 interpreter with no significant consequence.

Re: Sunsetting Python 2

#333

Post by radlad »

theelous3 wrote: post #65
tonyedgecombe wrote: post #11

Earlier quoted context omitted.

I wonder if they would have saved themselves five years of grief if they had done this five years ago.

Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2…

I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago.

Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?

Re: Sunsetting Python 2

#334

Post by mikepurvis »

weberc2 wrote: post #327
mikepurvis wrote: post #284

Earlier quoted context omitted.

Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought. It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.

No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.

The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago.

This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.

Re: Sunsetting Python 2

#335

Post by mistrial9 »

> We need to sunset Python 2 so we can help Python users.

We need to so we can . That statement is boilerplate manipulative garbage.. its ok to speak this way because you agree with the goal ?

Re: Sunsetting Python 2

#336

Post by jacquesm »

jsjohnst wrote: post #162
jacquesm wrote: post #150

Earlier quoted context omitted.

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…

> I just compiled a pretty large project from the stone age using a modern day compiler. Ok, now do the reverse. ;) The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.

> Ok, now do the reverse. ;)

Excellent point, conceded.

But backwards compatibility is the more useful direction to me, I can see however that if your job is to take a modern day application and compile it for a platform for which there is no modern day compiler that you're going to be in a special kind of hell for a long long time if the project has any size at all.

Re: Sunsetting Python 2

#337

Post by adamc »

braythwayt wrote: post #179
PeterisP wrote: post #152

Earlier quoted context omitted.

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 th…

This x 1000. “The free libraries we chose to depend upon haven’t migrated.” Do you have programmers? “Of course.” Put them to work. “We have other priorities.” Well then. Your choice, your outcome.

This is dumb. You're blaming people who probably don't get to call the shots. The managers who do have the ability to make different decisions are, themselves, often under the gun to meet other commitments.

Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.

The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.

Re: Sunsetting Python 2

#338

Post by tcd »

CJefferson wrote: post #269
capitol_ wrote: post #163

Earlier quoted context omitted.

If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.

To be honest, never. I work on a C program that's about 30 years old. We've slowly moved, at our own pace, to C99, then added some C++ here and there. I don't ever want to have a forceful change, where I have to go and edit code which has worked correctly for over 15 years, just to make a compiler happy.

Yeah, sorry buddy, but that's just not how modern software dev works. Platforms change, code gets outdated, and whilst older platforms "work", they're likely not taking advantage of all the features that have been added to platforms since that time.

It's much easier/better when you are forced into dealing with the change. At least people can laugh at how annoyed others get when they cry "but you broke everything!".

It's called progress. Get with the times or get outdated.

Re: Sunsetting Python 2

#339

Post by adamc »

hobofan wrote: post #191
SiempreViernes wrote: post #157

Earlier quoted context omitted.

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.

This. For most organizations, the effective window has only been 2-3 years.

Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.

Post reply on HN