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

681–690 of 733 posts

Re: Sunsetting Python 2

#681

Post by protomyth »

price wrote: post #645
protomyth wrote: post #528

Earlier quoted context omitted.

The GP post missed the fundamental difference between keeping COBOL running and keeping Python 2 running. Python 2 was also PSF's interpreter. IBM handling a COBOL upgrade like PSF handling the 2-3 transition would be unacceptable.

> IBM > PSF These are two very different kinds of institutions! People who need COBOL support from IBM are paying a lot of money. Giant piles of money can get you many kinds of help that people won't volunteer to do for free... among them, maintaining ancient software in amber. If you need Python 2 support and you are willing (and able) to pay the kind of money that IBM's customers pay for COBOL support, you'll be OK…

To circle back to the original point, no COBOL committee would break commonly running COBOL programs like the Python 2-3 transition. Using COBOL in an example with Python is just wrong. Maybe the break is justified, maybe it isn't, but some languages do a lot of work to make sure things continue to work.

Re: Sunsetting Python 2

#682

Post by Tempest1981 »

Last I checked, macOS doesn't include python3, just python2. I wrote a handy tool for our team, but nobody uses it because they don't have python3. Now I have to play sysadmin on dozens of machines.

A few had 3.5, but I used 3.6.

What can be done to make this easier? I.e. why isn't python3 pre-installed by now? esp 3.6 or 3.7?

Re: Sunsetting Python 2

#683

Post by orblivion »

sametmax wrote: post #176
EnderMB wrote: post #103

While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a…

> I'm still surprised that it's taken this long to finally close support That's because the Python community is too nice. When Ruby or node broke compat, they just said "move or die". People moved. When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair. They got an extension of 5 more years. People still complained…

Something about the "too nice" thing rubs me the wrong way. You gotta respect the people who develop the software. At the same time, the way people are deemed "complainers" reeks of contempt for the users. Yes, the users sometimes take your free work for granted. But you offered it. If you don't like the expectations that users assume are attached to it, you should say so upfront so they can become entangled with Ruby instead.

I don't think I disagree with your point in practice. Maybe in some details. I just don't think that not being credible in your plan to drop support on a given date is necessarily such a "nice" thing to do. You could say it's a "weak" thing to do. It doesn't help people prioritize the move and eventually hurts people by putting them into a jam on the day finally comes here. I think the ideal thing would be to break compatibility piece by piece, assuming it's really necessary, but be _understanding_ about it. Tell people "we understand that this is inconvenient for a certain number of people but have to cut it off at some place", not "stop complaining about free stuff".

Re: Sunsetting Python 2

#684

Post by gnulinux »

bscphil wrote: post #506
shscs911 wrote: post #454

Earlier quoted context omitted.

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.

> I am perfectly capable of maintaining python 2 myself.

That's a very strange quote. I want to have this much self-confidence.

Re: Sunsetting Python 2

#685

Post by nvrspyx »

Tempest1981 wrote: post #682

Last I checked, macOS doesn't include python3, just python2. I wrote a handy tool for our team, but nobody uses it because they don't have python3. Now I have to play sysadmin on dozens of machines. A few had 3.5, but I used 3.6. What can be done to make this easier? I.e. why isn't python3 pre-installed by now? esp 3.6 or 3.7?

Because Apple is notorious for using outdated libraries in macOS, like OpenGL. They included Python, but it was never a real focus to stay up to date since it was primarily to support legacy software.

With that said, Apple will not be including Python (or the other scripting languages like Ruby or Perl) at all starting with Catalina.

Re: Sunsetting Python 2

#686

Post by gnulinux »

carapace wrote: post #524
ARandomerDude wrote: post #437

Earlier quoted context omitted.

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.

I just realized I didn't answer your actual question, sorry. > what is it that you like about Python 2? I came from C and Pascal so from that POV Python is a rich and delicate syntactic and semantic gravy over the same basic functionality plus shell (Python was originally the shell language of the Amoeba distributed OS†). Things that might not seem that big a deal these days were a revelation to me when I started wit…

But all of these are in python 3 too?

Re: Sunsetting Python 2

#687

Post by [deleted] »

afiori wrote: post #634
ttraub wrote: post #203

Earlier quoted context omitted.

Me three! It happens all too often that an example Python script fails in one, then succeeds in the other. I'm also a casual Python user, trying to ramp up because of its obvious popularity and utility. I wish that the basic syntactical changes could have been designed to be more backward-compatible. But, eventually I suppose, python2 will just be a footnote in history.

I'm afraid it will forever remembered as a cautionary tale of a bad transition.

[deleted]

Re: Sunsetting Python 2

#688

Post by gnulinux »

musicale wrote: post #567

This would never have been such an unpleasant issue if Python 3 hadn't broken backward compatibility in very annoying ways; one of the more inexcusable examples was removing the print statement, a convenient piece of syntax that dates to antiquity, and which could have peacefully coexisted with the print() function in Python 3. Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p

You can fix that programmatically.

Re: Sunsetting Python 2

#689

Post by paulmd »

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.

There is also the third choice - you don't migrate and keep doing your job (developing features) on the legacy code base. Things like certificates will have ad-hoc solutions pushed whether you like it or not, and the language will keep trundling along.

If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.

This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.

This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.

Re: Sunsetting Python 2

#690

Post by herbstein »

alexhutcheson wrote: post #671
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…

[not speaking on behalf of any employer, opinions my own] I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer l…

> The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely.

Compiler errors sure would be handy here :^)

Post reply on HN