Live data from Hacker News

Sunsetting Python 2

python.org

431–440 of 733 posts

Re: Sunsetting Python 2

#431

Earlier quoted context omitted.

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

Hint for Hacker News commenters: 100% of the time, if your comment includes grammar or style advice, you can safely delete it and the discussion will lose no value. It's just a way to say "I'm smart" or "look at me" that sounds helpful but really isn't. In this case, you could have said nothing.

[deleted]

Re: Sunsetting Python 2

#432
post #124

Earlier quoted context omitted.

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

It's interesting seeing who the holdouts are, though. Less than a year ago, the CEO of Sentry (the crash reporter) locked a Github thread with essentially "we'll get there when we get there, sometime in or after 2020." But then, as late as 2016 their stance was pretty much that they would never migrate, so I suppose it's not surprising that they aren't super prepared for it: https://github.com/getsentry/sentry/issues…

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 refusing to migrate. (I'll probably have to find an alternative to ebook-convert, the command line tool that's the only part of Calibre I use, or maybe I'll rewrite it in Python 3 myself.)

Re: Sunsetting Python 2

#433

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 don't know... I don't really consider myself part of the HN echo-chamber (who does, I guess?). I hear "use case" fairly regularly here at our university, among non-technical staff in our academic support units. Perhaps we've indoctrinated them over the years...

Regardless, I would argue that "use case" has a quite specific and useful meaning that goes beyond mere corp-speak. I wouldn't use in conversation at a neighbourhood barbecue, but in a technical context (like a discussion of Python) the usage seems perfectly fine.

Re: Sunsetting Python 2

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

> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful d…

[deleted]

Re: Sunsetting Python 2

#435

Earlier quoted context omitted.

Not just RedHat - Google and Amazon have LTS that they're providing that will most likely include some flavor of 2.7. Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time. Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.

[resolved]

Amazon; thanks. I got my threads crossed.

Re: Sunsetting Python 2

#436
post #328

I'm happy this finally happened, even though I've been clinging to Python 2.7 for quite some time. I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7. In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you…

pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!

Re: Sunsetting Python 2

#437

Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…

Out of curiosity, what is it that you like about Python 2? Not attacking you, just curious. I've never used Python professionally (mostly Ruby and Clojure), so I don't have a horse in this race.

Re: Sunsetting Python 2

#438

Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curat…

> I just want to keep using Python 2.

Honestly curious as to why you would prefer to stay behind?

Re: Sunsetting Python 2

#439

A popular library that has unfortunately not transitioned to Python 3 yet is rospy (which is part of the larger ROS ecosystem for robotics). It is the last framework that prevents me to fully embrace Python 3 for my everyday work. I sincerely hope the robotics community will eventually port rospy (and other ROS-related libraries) to Python 3. I am, however, very happy to see that ROS2 (the next iteration of ROS) uses…

I'm in the same boat. It bothers me that my only option will be to rewrite in Python 3. Unless they provide a very clear migration path, I'm far more likely to just remove ROS entirely, unfortunately.

Re: Sunsetting Python 2

#440

Earlier quoted context omitted.

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that…

I am not sure what you want to say with your comment? That you move to another language as soon as there are breaking changes because you are invested as a user and therefore dissapointed? While this is a valid reason, it's just the way languages work. Some prioritize getting the language right and other backwards-compatibility. If your argument is categorical (languages that make breaking changes are bad) then indee…

This is a bit and oversimplified, but it also seems a bit weird, to me, to respond to a situation of "man it's going to be really annoying to rewrite all this code" with "You know what sounds like a better option? Rewriting all this code!"
Post reply on HN